מה זה boilerplate ומדוע אנו משתמשים בו? נחיצות מדריך סגנון קידוד

בטכנולוגיית המידע, לוח דוד הוא יחידת כתיבה שניתן לעשות בה שימוש חוזר שוב ושוב ללא שינוי. על ידי הרחבה, הרעיון מיושם לפעמים על תכנות רב פעמי, כמו ב"קוד הדוד ".

הסכמים משפטיים, הכוללים את התנאים וההגבלות של תוכנה וחומרה, משתמשים בשפע בפלטות הדוד.

לדוגמא, עורך דין עשוי לתת לך חוזה לחמישה עמודים לחתימה, אך רוב החוזה הוא צלחת דוד - כלומר זה זהה לכל מי שמקבל את החוזה, עם רק כמה שורות שהשתנו פה ושם.

בתכנות מחשבים, קוד boilerplate או boilerplate מתייחס לחלקי קוד שיש לכלול במקומות רבים ללא שינוי או ללא שינוי. משתמשים בה לעיתים קרובות כאשר מתייחסים לשפות הנחשבות מילוליות , כלומר על המתכנת לכתוב הרבה קוד כדי לבצע עבודות מינימליות.

לדוגמה, בפיתוח אתרים, boilerplate פשוט עבור HTML ייראה כך:

Hello world! This is HTML5 Boilerplate.

תוכל להציג את כל המאגר כאן:

h5bp / html5-boilerplate

html5-boilerplate - תבנית חזיתית מקצועית לבניית אפליקציות או אתרי אינטרנט מהירים, חזקים ומותאמים. github.com

בשנות ה -90 של המאה הקודמת, לוחית הדוד יצוקה או הוטבעה במתכת מוכנה לבית הדפוס והופצה לבתי עיתונים ולפירמות ברחבי ארצות הברית. עד שנות החמישים אלפי עיתונים קיבלו והשתמשו בפלטה מהסוג הזה מהספק הגדול ביותר במדינה, איגוד העיתונים המערבי. חברות מסוימות שלחו גם הודעות לעיתונות כצלחת הדוד, כך שהיה צריך להדפיס אותן ככתוב.

מרבית מפתחי האתרים המקצועיים יצרו אוסף של נכסים וקטעי קוד שהם עושים בהם שימוש חוזר בפרויקטים כדי להאיץ את הפיתוח. ישנם כמה דפוסים אוניברסליים או כמעט אוניברסליים שכל האתרים חולקים במשותף. במקום לבנות מחדש אותם ברציפות, רוב המפתחים מתחילים להעתיק את הקוד בו השתמשו עבור פרויקט דומה ואז מתחילים לשנות אותו.

יש מפתחים שמזהים את הערך של תבניות ההתחלה הללו של Boilerplate ולוקחים את הזמן בכדי להפוך את ה- Boilerplate לגנרי יותר ולשתף אותם באופן מקוון לשימוש אחרים.

זה לא מוגבל רק לפיתוח אתרים. הוא משמש מעבר ל- AI / ML מכיוון שיש יותר מסגרות וספריות שהולכות וגדלות.

מאפיינים הכרחיים של צלחת הדוד לפרויקטים גדולים (מוכנים לייצור)

• תיעוד טוב וקריא?
• מבנה קוד עם רמת הפשטה עמוקה יותר
• עוקב אחר תקן קידוד תקין
• יש כלי CLI (לאב טיפוס מהיר והתקנה)
• ניתן להרחבה?
• כלי בדיקה קלים
• מודולי API נחוצים
• תמיכה בינלאומי ולוקליזציה?
• פיצול קוד
• קוד שרת ולקוח להתקנה
• מבנה ניווט וניתוב נכון?

לאחר כל המפרט המינימלי הזה, עליך להתחיל לערוך ולשנות את הקוד על מנת לבנות את הפרויקט שלך.

יש כמה חברות ביג טק שאפילו בונות צלחת משלהן. הם משתמשים בו לפרויקטים בהתאמה ודומים לאורך זמן.

דוגמא מושלמת לכך תהיה הבישול של react.js:

תגובת-boilerplate / תגובה-boilerplate

react-boilerplate -: fire: בסיס מדרגי מאוד, לא מקוון-ראשון עם חווית המפתח הטובה ביותר ומיקוד ... github.com

פלטת דוודים לפרויקטים קטנים יותר (פיגומים)

סוגים אלה של פלטות דוודים הם בדרך כלל סוג של "ערכות התחלה" או באופן מקצועי זה נקרא "פיגומים". משתמשי היעד העיקריים שלהם הם מפתחים מתחילים או מאמצים חדשים.

הוא מתמקד באב טיפוס מהיר על ידי יצירת אלמנטים הנחוצים רק לפרויקטים חדשים. אלה דורשים פחות פונקציונליות ואינם ניתנים להרחבה לאורך זמן ופרויקט.

מבנה הקוד שלהם לא מורחב הרבה ואינו כולל שכבת הפשטה עמוקה יותר מכיוון שמשתמשים צריכים לבנות רק תכונות ליבה. זה מבטל את הצורך בתוספות שירות נוספות.

הדוגמה הפשוטה ביותר היא הבישול של פייסבוק ליצור-תגובה-אפליקציה:

facebookincubator / create-react-app

create-react-app - צור React apps ללא תצורת build. github.com

מה ההבדל בין צלחת דוד לתבנית?

כפי שקובע בבירור יואכים פנס, boilerplate הוא משהו שאתה מעתיק ומדביק ופשוט מוסיף למסמך. זה עולה לרוב בחוזים שבהם משתמשים בשפה ומשתמשים בה מחדש, ומאייתים דברים כמו תנאים וסייגים.

סופרים משתמשים בתבניות כמודלים , לפעמים עם השפעות שליליות. במונחים רחבים, תבנית היא מודל או תבנית המשמשים ליצירת אובייקטים חדשים. בכתב, זוהי צורה סטנדרטית של משהו כמו קורות חיים שכותבים יכולים להשתמש בהם בכדי לבטא את הגרסאות שלהם.

בניגוד לפלטות דוד, תבניות מותאמות לשימוש מסוים. הבעיה התעוררה מבחינתי כאשר התלמידים השתמשו בתבניות וורד לקורות החיים שלהם, וכולם בסופו של דבר נראים אותו הדבר.

הן תבניות והן צלחות הדודיות יכולות להפוך את הכתיבה העסקית לגנוזת ומלאכותית אם משתמשים בה בצורה לא חכמה.

מדריך סגנון לכתיבת קוד

לא משנה אם אתה משתמש ב- boilerplate או לא, ישנם כמה סטנדרטים שאחריהם חברות לכתיבת קוד. אחד מהם הוא מדריך הסגנון. הוא מנסה להסביר את הסגנונות והדפוסים הבסיסיים המשמשים חברות או ארגונים שונים. זה בדרך כלל כלל שעובדים חייבים לאמץ את מדריך סגנון הקידוד של החברה שלהם.

מדריך הסגנון מתאר טונות של כללים לכתיבת קוד, כמו הזחה של כרטיסיות ומרווחים, שמות של משתנים ופונקציות, כתיבת הערות נחוצות, עיצוב, מבני קבצי מקור, שימוש בשיטה נכונה של מבני נתונים, הימנעות מהנפה, סקופ, הצהרות בקרה ו הרבה יותר.

סגנונות תכנות בדרך כלל עוסקים במראה החזותי של קוד המקור במטרה לקרוא. תוכנה קיימת זה מכבר המפרמט את קוד המקור באופן אוטומטי, ומשאיר קודנים להתרכז בשמות, בהיגיון ובטכניקות גבוהות יותר.

כנקודה מעשית, שימוש במחשב לעיצוב קוד המקור חוסך זמן, ואז ניתן לאכוף תקנים כלל-חברתיים ללא דיונים. (מקור - Wiki).

אלו כמה דיונים נפוצים כמו: Tabs v Spaces מלחמה קדושה , בחירת קוד IDE מושלם , וכן הלאה. הדבר המעניין הוא שאתה יכול להיות מעורב בדיונים האלה שקורים בעיקר ב- Reddit . אתה יכול גם להשתתף בכמה מתשאלות ותשובות של stackoverflow .

עבור מפתחי אתרים, מדריך הסגנון הנפוץ ביותר עבור JS הוא מדריך סגנון ה- JavaScript של Airbnb. זה קוד פתוח וכולם יכולים לתרום.

airbnb / javascript

javascript - מדריך סגנון JavaScript github.com

אם מישהו מוטל בספק מדוע Javascript זקוק למדריך סגנון, קרא את התשובה השנייה של גיליון זה על ידי הריסון שוף, המתכנת ב- Airbnb .

מדוע JavaScript צריך מדריך סגנונות? · גיליון מס '102 · airbnb / javascript

אחד החלקים האהובים עליי בקהילת JavaScript הוא שאנשים בוחרים לכתוב אותו בכל כך הרבה דרכים שונות ... github.com

להלן מספר מדריכי סגנון לכמה מהשפות הפופולריות יותר בימינו:

מעצב קוד DotNet

Java: Google-Java-Format

סגנון Javascript סטנדרטי (שונה מ- Javascript של Airbnb)

תקני קידוד PHP תיקון r

פייתון: ה- YAPF של גוגל

רובי: רובוקופ

עוד מ- Boilerplate: קונספט ל- OOP

בתוכניות מונחות עצמים, שיעורים מקבלים לעיתים קרובות שיטות לקבלת קביעת משתני מופע והגדרתם. ההגדרות של שיטות אלה יכולות להיחשב לעתים קרובות כצלחת דוד.

למרות שהקוד ישתנה ממעמד אחד למשנהו, הוא מבנה סטריאוטיפי מספיק, כך שהוא ייווצר בצורה טובה יותר באופן אוטומטי מאשר נכתב ביד.

לדוגמה, בכיתת Java הבאה המייצגת חיו מחמד, כמעט כל הקוד הוא מוכן מראש למעט ההצהרות של חיות מחמד , שם , וכן בעלים :

public class Pet { private String name; private Person owner;

public Pet(String name, Person owner) { this.name = name; this.owner = owner; }

public String getName() { return name; }

public void setName(String name) { this.name = name; }

public Person getOwner() { return owner; }

public void setOwner(Person owner) { this.owner = owner; }}

הגדרת Boilerplate הופכת לגלובלית יותר בשפות תכנות רבות אחרות בימינו. זה בא משפות OOP ושפות היברידיות שהיו פעם פרוצדורליות אך הפכו ל- OOP. כעת יש להם אותה מטרה לחזור על הקוד שבנית עם מודל / תבנית / מחלקה / אובייקט, ולכן הם מאמצים מונח זה. אתה יוצר תבנית, והדברים היחידים שאתה עושה עבור כל מופע של תבנית הם הפרמטרים הבודדים.

החלק הזה הוא מה שאנחנו מכנים boilerplate. אתה פשוט משתמש בקוד שעשית ממנו תבנית, אך עם פרמטרים שונים.

Boilerplate כ- API

מכיוון שאתה פשוט משתמש מחדש בקוד התבנית עם פרמטרים שונים, זה מרמז שנוכל לבנות ממשקי API לשימוש חוזר שזקוקים רק לשינוי קלט ופלט.

סיכום

"קוד Boilerplate" הוא כל קוד לכאורה שחוזר על עצמו שמופיע שוב ושוב על מנת להשיג תוצאה שנראית כאילו היא צריכה להיות הרבה יותר פשוטה.

כתבתי מאמר זה מכיוון שקיבלתי לאחרונה הוראה על ידי ראש צוות ללמוד על סוגים רבים של צלחת הדוד שעשויים להתאים לפרויקט שלנו. אז נאלצתי לחפש אחר לוח הדוד המושלם.

כל סוג של משוב יוערך! הרגש!