#5 Developer's First Rule

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ולסיום, אזהרה חשובה: השימוש בכלל ה"תמצא את מי להאשים" עלול להיות ממכר! לאחר שימוש יתר עלול להיווצר מצב בו המשתמש מתחיל באמת להאמין שהוא לא אשם. ראו הוזהרתם!

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

מתחת לקו – דברים שלא חייבים לקרוא

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

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

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

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