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

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

קרדיט תמונה: Michael Blann / Getty Images Israel

קרדיט תמונה: Michael Blann / Getty Images Israel

בתוכנה, כמו בתחומים אחרים – יש כללים שעוזרים לנו לכוון בצורה יעילה יותר את העשייה שלנו.

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

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

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

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

1. Conway’s Law – ארגוני ארכיטקטורה

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

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

2. עיקרון פארטו – כללי

"במקרים רבים, 80% מההשלכות (effects) נובעות מ-20% מהגורמים הפעילים (causes)"

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

וריאציה א: מוצר
"80% מהערך של מוצר, ניתן להשיג ב 20% מההשקעה"

וריאציה ב: קוד
"80% מהבאגים המשמעותיים, נובעים מ 20% מאזורי הקוד"

וריאציה ג: ארגוני
"כ 66% מהעשייה המשמעותית, נעשית על ידי כ 33% מהמתכנתים", מה שמתבטא גם ב:

3. כלל הכישרון ארגוני – טכנולוגיה

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

4. עקרון הדורות המקוצרים (short generations) – כללי

"כל עשור יהיה על איש התוכנה ללמוד 50% מהמקצוע מחדש"

וריאציה: "כל עשור, 100% מהטכנולוגיות שבשימוש – יתחלפו".

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

5. עקרון ה-Code is everything – קוד

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

לסירוגין: "מסמכי Design אינם מתקמפלים".

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

6. עקרון ה-Not Invented Here (בקיצור: NIH) – קוד הטיה אנושית

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

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

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

"Code Rots"

הסבר: קוד שלא עובר חידוש (refactoring) – הולך ו"נרקב" ואיכותו פוחתת. השקעה רק בפיצ'רים, ללא השקעה בחידוש הקוד תביא את הקוד למצב שאיננו ניתן יותר לתחזוקה, ויש לכתוב אותו מחדש. Guideline מקובל לאורך החיים של תוכנה עד לשלב בו יש לכתוב אותה מחדש (אם לא בוצעו פעולות refactoring, "הזרמת חמצן") הוא 3 עד 5 שנים.

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

8. Lubarsky's law of Cybernetic Entomology – קוד

"תמיד יש עוד באג אחד במערכת"

למשל: לאחר 11 שנה של שימוש המוני, נתגלה באג באלגוריתם ה Sorting של ספריית Java הסטנדרטית. (באג מאוד פינתי, כמובן).

שם נוסף: Linus’s Law (הופרך כמיתוס)

"Given enough eyeballs, all bugs are shallow".

הסבר: בהינתן מספיק עיניים בוחנות – כל הבאגים יימצאו.

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

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

9. ללא שם (Michael Nygard) – פרודקשן

"משתמשים מגבירים בצורה בלתי-מוגבלת את אי-יציבות המערכת"

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

10. Wirth’s law – פרודשיין

"התוכנה הופכת איטית בקצב מהיר יותר, מהקצב בו חומרה נהיית מהירה"

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

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

11. Sturgeon’s Revelation – כללי

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

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

ב-90% מהמקרים אנו צפויים להתאכזב ממה שציפינו – כי בניית הציפיות הייתה טובה יותר מסיפוקן".

וריאציה: "90% ממקרי האימוץ של טכנולוגיה חדשה – יהיו שגויים או לא יעילים".

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

12. The Hype Cycle – טכנולוגיה

hype lifecycle

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

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

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

מקור: Gartner.

מקור: Gartner.

13. כלל תקורת ההטמעה – מתודולוגיה וטכנולוגיה

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

14. כלל ההקשר השגוי – מתודולוגיה

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

15. חוק ה 90-90 – ניהול זמנים / פרויקטים

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

יש כמה כללים דומים שמבטאים רעיון דומה:

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

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

16. חוק פרקינסון – ניהול זמנים / פרויקטים

"העובדה מתרחבת על מנת למלא את לוח הזמנים שניתן לה" (רפרנס)

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

17. Brook’s Law – ניהול זמנים / פרויקטים

"הוספת אנשים לפרויקט מאחר ובשלב מתקדם – רק תגרום לפרויקט לאחר יותר" (רפרנס)

הסיבות:

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

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

18. The Bergman Dilation ("התרחבות ברגמן") – ניהול זמנים / פרויקטים

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

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

19. מיתוס הנחמה הניהולית – ארגוני

"חוסר בהירות גורמת למפתחים לשחיקה, לא לאתגר"

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

הפוסט פורסם במקור בבלוג Software Archiblog

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

8 Comments on "19 כללי הפיזיקה של התכנות - כללים של הנדסת תוכנה שלא ניתן להתחמק מהם"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
שין
Guest

יותר קשור לניהול פרויקטים מאשר לכתיבת קוד

עילצ
Guest

מעניין תודה

Shimon Doodkin
Guest

18 לא ברור

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

אכן קשור יותר ל"חוקים" בפרויקטים של תוכנה

עדי
Guest
הכללים של הכללים: 1. מספר הכללים יהיה אי-זוגי או ראשוני, כאילו הכללים זוקקו או צומצמו למצב הטהור שלהם. 2. קח אמת טריוויאלית, הפוך סיבה ומסובב, הוסף אחוזים שרצוי שיסתכמו במאה, והנה כלל ברזל חדש נולד. 3. אם שם החוק לא משכנע, השאר באנגלית. אם עדיין לא משכנע, קרא לו על שם מהנדס אנגלי מהמאה השמונה עשרה. אם בכל זאת לא משכנע, הוסף לשמו את המילה "תפוקה" או "זהב". אם זה לא עוזר השתמש בנשק יום הדין, והוסף מיחה בלטינית. 4. שתול כל שניים שלושה כללים, כלל שמשמעותו חנופה בלתי מסוייגת לבעלי המקצוע עליהם חלים הכללים, או לחילופין, כלל שמשמעותו שכל… Read more »
do
Guest

כתבה מעולה

Avraham Avi Hecht
Guest

usually whatever can go wrong happens and isn't anticipated nor documented ;)

אולדסקול
Guest

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

שאול מזור
Guest

מעולה כתמיד!

wpDiscuz

תגיות לכתבה: