כללי התיכנותיקה - 19 כללים של הנדסת תוכנה שלא ניתן להתחמק מהם

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

מכיוון שאין להם שם מוכר, נתתי להם שם: "כללי התיכנותיקה" (הלחם לשוני של "תכנות" ו"פיסיקה").

מקור: http://potluckcomics.com/links-laws-of-physics

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

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

הנה הם לפניכם:



Conway’s Law ארגוני ארכיטקטורה
"מבנה התוכנה והקשרים בין חלקיה, סופם שיהיו שיקוף של המבנה הארגוני של הארגון בה היא מפותחת" (רפרנס)
הסבר: המבנה הארגוני הוא כוח חזק מאין כמוהו, שלא ניתן להתעלם ממנו. למשל: אם אתם מתכננים קומפיילר בין 4 שלבים, אך יש לכם 3 צוותי פיתוח - סביר שבסופו של דבר אחד השלבים יהיה אנמי, ובפועל יהיה לכם קומפיילר עם 3 שלבים. הפתרון - להכיר במציאות: או שתתכננו קומפיילר בין 3 שלבים, או שתארגנו את האנשים ב 4 צוותים.


עיקרון פארטו כללי
"במקרים רבים, 80% מההשלכות (effects) נובעות מ 20% מהגורמים הפעילים (causes)"
רקע: ידוע גם בשם "כלל 80-20", והוא כלל שנוסח על ידי הכלכלן האיטלקי וילפרדו פארטו, לאחר שראה את פיזור העושר באיטליה במאה ה-19 (כיום, פיזור העושר הוא קיצוני הרבה יותר, ואולי לא משקף כבר "התפלגות טבעית של סיבה ותוצאה").
וריאציה א: מוצר
"80% המערך של מוצר, ניתן להשיג ב 20% מההשקעה"
וריאציה ב: קוד
"80% מהבאגים המשמעותיים, נובעים מ 20% מאזורי הקוד"
וריאציה ג: ארגוני
"כ 66% מהעשייה המשמעותית, נעשית על ידי כ 33% מהמתכנתים", מה שמתבטא גם ב:

כלל הכישרון ארגוני טכנולוגיה
"האלמנט שמנבא בצורה הטובה ביותר הצלחה או כישלון של תוכנה הוא לא הטכנולוגיה, שפת התכנות, או ה Framework - אלא המתכנתים שכותבים את התוכנה"

עקרון הדורות המקוצרים (short generations) כללי
"כל עשור יהיה על איש התוכנה ללמוד 50% מהמקצוע מחדש"
וריאציה: "כל עשור, 100% מהטכנולוגיות שבשימוש - יתחלפו".
מי שלא מוכן / מבין את ההשקעה הנדרשת בכדי להישאר במקצוע - ייפלט מהתחום במשבר הראשון לאחר מעבר של "דור".


עקרון ה-Code is everything קוד
"אפשר להתווכח כמה שרוצים, האמת נמצאת במקום אחד: בקוד".
לסירוגין: "מסמכי Design אינם מתקמפלים".
הסבר: להנדסת תוכנה יש הרבה תוצרים מופשטים: רעיונות, מסמכים, תחזיות, ותוכניות. יש תוצר אחד שהוא מוחשי וקונקרטי מאין כמוהו: הקוד. חשוב לזכור שמה שקובע זה לא מה שתכננו, רצינו או התכוונו שיקרה - התוכנה היא מה שכתוב בקוד.


עקרון ה Not Invented Here (בקיצור: NIH) קוד הטיה אנושית
"הדשא של השכן ירוק יותר, אך הקוד של השכן הוא גרוע, לא מובן, ולעתים פשוט מטופש"

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

העיקרון הביולוגי של הקוד (הדוד בוב) קוד

"Code Rots"
כלומר: קוד שלא עובר חידוש (refactoring) - הולך ו"נרקב" ואיכותו פוחתת. השקעה רק בפיצ'רים, ללא השקעה בחידוש הקוד תביא את הקוד למצב שאיננו ניתן יותר לתחזוקה, ויש לכתוב אותו מחדש. Guideline מקובל לאורך החיים של תוכנה עד לשלב בו יש לכתוב אותה מחדש (אם לא בוצעו פעולות refactoring, "הזרמת חמצן") הוא 3 עד 5 שנים.
היבט נוסף הוא העיקרון ש"קוד שלא נקרא כחצי שנה - הופך לקוד זר ולא מוכר" (ידוע כ Eagleson's Law). רמת הקריאות של הקוד, ועוצמת המסרים והעקרונות המשתקפים מהקוד - משפיעים רבות על קצב ה"ריקבון" של הקוד.


Lubarsky's law of Cybernetic Entomology קוד
"תמיד יש עוד באג אחד במערכת"
למשל: לאחר 11 שנה של שימוש המוני, נתגלה באג באלגוריתם החיפוש הבינארי של ספריית Java הסטנדרטית. (באג מאוד פינתי, כמובן).


לחלופין: Linus’s Law - הופרך כמיתוס
"Given enough eyeballs, all bugs are shallow".
כלומר: בהינתן מספיק עיניים בוחנות - כל הבאגים יימצאו.
הכלל נקרא על שם לינוס טורבאלדס, יוצר הלינוקס, מכיוון שהוא מבטא סוג של הנחה סמויה של קהילת הקוד הפתוח. הכלל לא הוגדר ע"י לינוס, אלא על ידי אדם אחר, אריק ריימונד.

הוכח מאז, במספר מחקרים, שיש תועלת שולית פוחחת משמעותית למספר ה Reviewers של קוד, ומעבר ל 3-4 reviewers כמעט ואין שיפור באיכות של קטע קוד (גם כי נותרים הבאגים הקשים יותר לגילוי, וגם כי אנשים מניחים שהקוד כבר נבחן בצורה מספיק טובה, ומסירים מעצמם אחריות / חשיבה ביקורתית).



ללא שם (Michael Nygard) פרודשיין
"משתמשים מגבירים בצורה בלתי-מוגבלת את אי-יציבות המערכת"
בנוסח אחר: "לעולם לא ניתן ליצור סביבת stating/testing שתחווה את כל הבעיות של סביבת production".
זו גם סוג של עקיצה למי שכותב תוכנה ללא משתמשים, ונמצא ב"אשליה" שהקוד שלו יציב, scalable, וכו'.
הכלל הוזכר לראשונה בספר (המצוין!) "!Release It"

Wirth’s law פרודשיין
"התוכנה הופכת איטית בקצב מהיר יותר, מהקצב בו חומרה נהיית מהירה"
הסבר: למרות שחומרה נעשית כל הזמן יותר מהירה (לסירוגין: שירות ענן נעשה זול), לא ניתן להסתמך על העובדה הזו בשיקולי ביצועים של תוכנה.
הרגרסיה הטבעית בביצועים של התוכנה (תוכנה שעדיין מוסיפים לה יכולות) היא מהירה יותר מהתקדמות הטכנולוגית של החומרה - ולכן תמיד יהיה צורך ב"שיפורי ביצועים" בתוכנה על מנת לשמר את רמת הביצועים שלה.


Sturgeon’s Revelation כללי
"90% מכל דבר זה שטויות"

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

The Hype Cycle טכנולוגיה

הסבר: טכנולוגיות חדשות נוטות לחזור אחר אותו מחזור של Hype שטכנולוגיות עבר עברו:

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

הנה דוגמה למיפוי של טכנולוגיות עכשוויות, והמיקום שלהן ב Hype Cycle:

לחצו להגדלה. מקור: Gartner.

כלל תקורת ההטמעה מתודולוגיה טכנולוגיה
אימוץ כלי או מתודולוגיה חדש, מפחית את הפריון ואיכות המוצר לתקופה מסוימת. התמורה המושגת מהמעבר לכלי / הטכניקה החדשה (בהנחה שהיא עדיפה להקשר) - תורגש רק לאחר זמן מה (נאמר: 6 חודשים).


כלל ההקשר השגוי מתודולוגיה
"אין רעיון טוב שלא ניתן להשתמש בו בצורה שגויה לחלוטין" (ידוע גם כ Flon’s Axiom)



חוק ה 90-90 ניהול זמנים / פרויקטים
"90% מהקוד - ייכתב ב 90% מהזמן. יתר עשרת האחוזים מהקוד - ייכתבו ב 90% נוספים מהזמן." (רפרנס)
יש כמה כללים דומים שמבטאים רעיון דומה:

• "הערכת חסר תינתן, גם כאשר אנו יודעים שאנו נוטים לתת הערכות חסר." (Hofstadter's Law)
• "הזמן המוערך לסיום פרויקט תוכנה הוא פונקציה מונוטונית עולה."
• "הזמן שנותר לסיום הפרויקט - הוא תמיד קבוע". (Hartree's Law)

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

חוק פרקינסון ניהול זמנים / פרויקטים
"העובדה מתרחבת על מנת למלא את לוח הזמנים שניתן לה" (רפרנס)
הסבר: אם הגדרנו של פרויקט נתון מוקצבים 6 שבועות עבודה, גם לו תאורטית יכולנו לסיים ב-4 שבועות - בלי לשים לב אנו נמלא את כל ששת השבועות שהוקצבו (בעזרת הפחתת מהירות, או הכנסת עבודה נוספת).


Brook’s Law ניהול זמנים / פרויקטים
"הוספת אנשים לפרויקט מאחר ובשלב מתקדם - רק תגרום לפרויקט לאחר יותר" (רפרנס)
הסיבות:

• יש זמן ramp-up עד שאנשים משתלבים בפרויקט ונהיים יעילים בו: זמן למידה וזמן הסתגלות של הסביבה אליהם.
• התפוקה השולית הפוחתת של כל עובד נוסף בפרויקט - יורדת. בהגדרה: פרויקטים קטנים יותר (מעט אנשים) הם יעילים יותר מפרויקטים גדולים.

צורה אחרת: "The bearing of a child takes nine months, no matter how many women are assigned"


The Bergman Dilation ("התרחבות ברגמן") ניהול זמנים / פרויקטים
"לא תמיד יש זמן לכתוב את הקוד בצורה נכונה, אך ברוב הפעמים יש זמן לכתוב את הקוד מחדש".

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

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



שיהיה בהצלחה!