לא רק יעילות: הכירו את הכלל הראשון להישרדות בהייטק
לפי אודי הרשקוביץ, באוניברסיטאות ובמכללות מלמדים את הסטודנטים איך לתכנת בצורה פונקציונלית, למרות שזה בכלל לא מה שחשוב. בטור הציני השבועי, הוא עורך לנו היכרות עם התכנות ההישרדותי, אשר ידאג לכך שכותב הקוד לא יפוטר ושירוויח כמה שיותר נקודות כדי להתקדם בעבודה
רוב העובדים החדשים שמגיעים לעבוד בהייטק הם בעלי ידע לא רע בכלל בתכנות. זה הרי אחד היתרונות המרכזיים בתחום של מדעי המחשב, שהחומר הנלמד בלימודים התאורטיים, שיעורי הבית והפרוייקטים הם דומים מאוד לעבודה המתבצעת בעולם האמיתי.
כמעט כל בוגרי האוניברסיטאות והמכללות, וכמובן שגם יוצאי יחידות המחשב הצבאיות יודעים פחות או יותר לתכנת, אבל כמעט כולם יודעים רק לתכנת תכנות פונקציונלי. מסיבות שאינן ברורות לי, גם באוניברסיטאות וגם במקומות העבודה לא מלמדים ואף מתעלמים מכללי התכנות ההישרדותי.
בקיצור: תמצאו את מי להאשים
ההבדל המשמעותי ביותר בין תכנות פונקציונלי ותכנות הישרדותי הוא כמובן במטרות של כתיבת הקוד. בתכנות פונקציונלי מטרות כתיבת הקוד הן לבצע בצורה יעילה וללא שגיאות משימות שהוגדרו מראש. בתכנות הישרדותי המטרה הראשית היא לדאוג לכך שכותב הקוד לא יפוטר, והמטרה המשנית היא לנסות להרוויח כמה שיותר נקודות במטרה להתקדם בעבודה.
והכלל הראשון של התכנות ההישרדותי פשוט מאוד: אף פעם אל תתחיל לכתוב קוד לפני שיש לך את מי להאשים במקרה ותהיה בקוד בעיה. או בניסוח המקוצר שלו: תמצא את מי להאשים.
זהו כלל בסיסי ביותר, שלוקח לא מעט זמן להפנים אותו ולדעת להשתמש בו באופן האופטימלי. היתרונות של כלל זה ברורים מאליהם לכל מתכנת מצוי, ומזכירים במידת מה את הכסת"ח הצה"לי. די מתבקש שלכל אחת ואחד תהיה תוכנית גיבוי מסודרת במידה ונעשתה פאדיחה בקוד. אלא שלעובדים חדשים וחסרי ניסיון יש שלוש בעיות במימוש כלל זה:
1. בתחילת הדרך העובדים החדשים כלל לא מודעים לחוק הראשון.
2. בהמשך, המודעות כבר קיימת, אך מחסום הבושה וחוסר הביטחון העצמי מונע מהעובד להאשים מישהו אחר.
3. לבסוף הבעיה הגדולה היא כמובן למצוא את האשם האלטרנטיבי וגם לדעת איך לבנות את תוכנית ההפללה.
הבעיה הראשונה נפתרה באמצעות כתיבת שורות אלה. כל מי שקורא טור זה כבר לא יוכל לטעון שהוא לא מכיר את הכלל הראשון. הבעיה השנייה אינה בעיה אמיתית. זהו מעין מחסום פסיכולוגי וירטואלי שרק נראה קשה. הדרך הפשוטה והיעילה על מנת לשבור מחסום זה, היא פשוט למצוא את ההזדמנות בה אחת מחברי הצוות לא נמצא לכמה ימים ולטפול עליו את האשמה לפאדיחה שלך.
עד שהוא יחזור מהחופש אף אחד כבר לא יזכור את הסיפור הזה, אבל מבחינתך, הניסיון החשוב בהאשמת האחר בוצע בהצלחה. לאחר מספר פעמים של האשמת מישהו אחר בפאדיחות שלך, הבושה הולכת ונעלמת לה והאשמת האחר הופכת למעין הרגל שני.
לטורים נוספים במדור:
היום שבו הפכתי למנהל קטן בחברת הייטק גדולה
איך הגיעה התוצאה של הדרבי לדו"ח השבועי?
המהפכה החברתית לצמצום מספר המיילים בעבודה
כל אחד נהיה צ'יף: כך נעלמו "פשוטי העם" מההייטק
חשוב: לא להגזים
כעת אפשר לעבור לחלק המרכזי של הטור בו אתאר מספר שיטות ידועות ובדוקות כיצד למצוא את מי כדאי להאשים בפאשלות שלך ובאיזה אופן.
האפשרות הטובה ביותר לכתיבת קוד ללא חשש שיאשימו אותך, היא לקבל בעלות על קוד של מישהו אחר שעבר תפקיד. אמנם רוב המתכנתים אוהבים לכתוב קוד חדש, אבל כשכותבים קוד חדש קשה מאוד להאשים מישהו אחר בבאגים שנמצאו בו.
לעומת זאת, כאשר עובדים על שינויים בקוד שמישהו אחר כתב זהו מצב של WIN-WIN. כלומר, על כל שיפור או תוספת מוצלחת בקוד אתה מקבל את מלוא הקרדיט. ומצד שני, כל דבר שלא עובד, או שאפילו הפסיק לעבוד בעקבות שינוי שלך, הוא באשמת זה שכתב את הקוד לפניך.
במידה ולא ניתן להאשים את המתכנת שעבר על המודול לפניך (מה לעשות, עד שהגעת הכל עבד מושלם, ורק כשהתחלת לעשות שינויים בקוד פתאום התחילו להיות בעיות) צריך למצוא אשמים אחרים. ישנן אפשרויות רבות את מי להאשים, והכל תלוי במצב. במצב של הקוד, במצב שלך ובעיקר במצב הרוח של הקורבן עליו הולך ליפול התיק. להלן אפשרויות ההאשמה הנפוצות ביותר, וכיצד יש להשתמש או לא להשתמש בהן.
ראשית, יש לזכור אף פעם לא להאשים את המנהל הישיר שלך. הדבר נכון גם במקרים שזו באמת אשמתו, מקרים שעל פי רוב אינם נדירים. ישנן שתי סיבות למה לא להאשים את המנהל הישיר: קודם כל, הוא יכול לפטר אותך. ודבר שני, זה לא יעזור להאשים את המנהל שלך. המנהל שלך מכיר את החוק הראשון טוב מאוד, שכן ללא שימוש בחוק זה הוא כלל לא היה נהיה מנהל, ויש לצפות שהוא מיד יפיל את האשמה חזרה עליך.
אחת האלטרנטיבות היותר בטוחות היא להאשים את הדוקומנטציה. כל שעליך לעשות הוא להגיד שאתה לא אשם, הרי עשית בדיוק מה שכתוב במסמך ההגדרות של הפרוייקט. כיוון שאף אחד לא באמת יודע מה כתוב במסמכים האלו, והרוב אפילו לא יודע איפה למצוא אותם, רוב הסיכויים שאף אחד לא יעלה עליך.
כמו כן אפשר, ואף רצוי, להטיל את האשמה בגרימת הבאג האחרון על הארכיטקטורה של המערכת, תוך תלונה רעשנית על כמה שהכל פה נורא מסובך, ואי אפשר לעשות שום דבר בלי לשבור משהו. במידה ומישהו מצוות הארכיטקטורה ינסה להתקומם נגד הטענה, תמיד אפשר לשלוף את הבאג האחרון בתור הוכחה ניצחת לסיבוכיות של המערכת, עובדה שהבאג קרה!
אם הבאג נמצא רק אצל הלקוח, מיד יש להטיל את האשמה על קבוצת הבדיקות שהייתה אמורה למצוא את הבעיה לפני שהגירסה שוחררה. זהו עיקרון חשוב מאוד שנקרא "ליקוי בעיות". בדומה לליקוי חמה בו השמש הגדולה אך רחוקה מוסתרת על ידי הירח הקטן אך הקרוב, כך בליקוי בעיות מסתירים בעיה גדולה שאירעה בעבר הרחוק (כלומר הבאג שלך) באמצעות בעיה קטנה יותר אבל שהתרחשה זה מקרוב (הפספוס של הבדיקות בלמצוא את הבאג).
ישנן עוד אפשרויות רבות נוספות, וככל שמתאמנים יותר מגלים עוד ועוד הזדמנויות.
ולסיום, אזהרה חשובה: השימוש בכלל ה"תמצא את מי להאשים" עלול להיות ממכר! לאחר שימוש יתר עלול להיווצר מצב בו המשתמש מתחיל באמת להאמין שהוא לא אשם. ראו הוזהרתם!
והמהנדס החכם אומר: הדבר היחיד שאפשר להאשים אותי בו, הוא שלא מצאתי את מי להאשים.
הכותב בעל נסיון ניהולי, וממשיך לצבור חוויות בהייטק על בסיס יומיומי. טורים ופוסטים נוספים שלו ניתן לקרוא בבלוג "פינת הקפה ".
לפנייה לכתב/ת 
