גם השנה, במה שהפך כבר למסורת, הוזמנתי להרצות על הנושא האהוב עלי Production time Debugging, בכנס ביצועים, שנערך כל שנה, אי שם. עצם העובדה שמרכזים פעם בשנה, קבוצה גדולה של אנשי שטח, לדון בנושא שיפור ביצועים, הינה דבר מבורך. כי במערכות גדולות, כל שניה שאתה חוסך, יכולה להיות מוכפלת בקלות, בפקטורים של עשרות אלפים (והיו כמה דוגמאות כאלה בכנס).
היום התחיל עם שיחת פתיחה, על נושא ביצועים בעולם ה IT. נושא הביצועים חותך את כל הרכיבים בארגון, ולכן צריך להתיחס לזה בתפיסה הוליסטית וכוללת. ומכאן הסיבה לכך שהוקם גוף יעודי למטרה הזו. מאחר וניתוח בעיות כאלה במערכות גדולות דורש מומחים (בדיוק כפי שיש רופא מומחה), יכולת להבין ולנתח הרבה מאד פרמטרים וכלי איסוף ברמת הארגון. ביומו של גוף מרכזי מאפשר לעשות את זה יותר יעיל, בטח בארגון שהתחלופה בו גבוהה. גוף כזה מתמקד באופן הגיוני בתהליך נכון (Process Plumber) ובכלים ושיטות (Bug Extermination).
הוצכרה גם השאלה הנצחית, מתי ובאיזה שלב של הפרויקט יש לעשות את זה עם התשובה הברורה מאליה (לפחות לחלק מאיתנו) שזה לא משהו שצריך לעשות בסוף, אלא כמה שיותר מוקדם, וצריך גם לזכור, שגם כשהמערכת כבר בשטח, צריך לערוך לה Tuning תקופתי. נושא הביצועים קושר כבדרך אגב, לעולם מלחמות הסיבר, שכן אחד מוקטורי התקיפה, זה העמסת תהליכים קימים. רציתי להעיר בנושא הזה, שבהרבה מהמערכות שטיפלתי בהן בתוקף תפקידי כמשמיד חקרים ושרברב של תהליכים, לא היה צריך תוקף חיצוני, הארכיטקטים והמפתחים שהקימו את המערכת, עשו את זה מספיק טוב.
בשלב הבא עלה על הבמה יאיר הורוויץ מ HP והציג את ה Performance Center 11 של HP. ה Performance Center זה גירסת ה Enterprise של Load Runner. אחת התוספות החזקות של הגירסה החדשה היא הקישור ל ALM, מה שמשלב את המערכת בצורה מלאה בכל תהליך הפיתוח. דבר חשוב נוסף הוא מעבר מהסתכלות פרטנית, להסתכלות מערכתית, של בעיות הביצועים. שילוב דרישות הביצועים ברמת הארגון ולא ברמת הפרויקט. בנוסף כל הצעצועים הצפויים, כמו תיזמון בדיקות בשעות שאין משתמשים, חלוקת משאבי בדיקות בין הבדיקות השונות וכו.
לאחר מכן עבר יאיר לדבר על ה Sire Scope, שהוא כלי לאיסוף רציף של מידע וניטור מערכות. החוזקה שלו היא שהוא מכיר את כל המערכות ולא רק את עולם המיקרוסופט, כך שאם יש לך מערכת הטרוגנית, ויש לך כמה ספקים, ומערכות כמו WebSpare של IBM ו מערכות Enterprise של Oracle בארגון. אתה מקבל את היכולת לנטר את כולם בנקודה אחת. וכמובן הוזכרו גם SLA, Tranding, Analysys ו Diagnostics ואפילו BSM.
הפנינה שתרם לי יאיר, היא הסיפור של השימוש בפיצה לבדיקת עומסים. פעם כדי לעשות בדיקות ביצועים, היו מרכזים את כל העובדים עם המחשבים שלהם בחדר אחד. קונים לכולם פיצה, על מנת להבטיח שכולם יגיעו. ואז מבקשים מהם שכולם ביחד, באותו רגע, ילחצו על ה Enter. כדי לייצר עומס על המערכת. ה Load Runner הוא סך הכל שיפור של התהליך, בזה שהחליף את המשתמש הפיזי במשתמש וירטואלי. ובכך חסך את תקציב הפיצה הארגוני. כמובן ש Load Runner נותן היום הרבה יותר ממשתמש וירטואלי, ויאיר לא שכח להזכיר את הפרוטוקולים החדשים שנוספו, כמו למשל תמיכה מלאה ב AJAX, הסתכלות ברמת ה UI באמצעות TruClient ולא רק ברמת ה Web Transport והקורולציות (דורש בשלב זה Fire Fox).
משם הכיתות התפצלו, אנשי ה DB הלכו לכיתה אחרת כדי לשמוע על שיפורי ביצועים ב SQL ממאיר דודאי ממיקרוסופט ישראל. אני דווקא נשארתי לשמוע תאור מרתק של תהליך שיפור ביצועים באחת המערכות שבה הושג שיפור תהליכים מ 4 שעות לעומת 4 שניות. הבעיה שהוצגה היא מערכת שעבדה שנים בלי בעיות ביצועים (כאילו). כשהשימוש במערכת עלה, ולאחר המעבר לדיווח יומי, לילה שלם כבר לא הספיק, כדי להוציא את כל הדוחות שנתבקשו. מה שגרם כמובן לכך, שביצועים הופך להיות נושא שדורש טיפול.
היחס בין 4 שעות ל 4 שניות הוא לא יחס קטן. וזה מעורר כמובן את השאלה, איך זה קורה, שקוד כזה דפוק יושב שנים במערכת, ופוגע בביצועים שלה מבפנים. ואף אחד לא עלה על זה, בשלב הפיתוח של המערכת. התשובה היתה שהנושא של Performance לא היה בראש של צוות הפיתוח מלכתחילה, ולא היתה אליו מודעות. וזה לא התבטא רק במודעות לביצועים, היו בקוד אזורים עם גושים ענקיים של קוד, שכל הכלים מצביעים על זה ששם יש בעיה, ועכשיו לך ותתקן משהו, בתוך כל הספגטי הזה.
אז להלן רשימה של כללים (עשרת הדברות) שהוצגו: עובד לאט, לא עובד – ברמת הפרט, לא עובד מהר לא עושים לקוד Check In. לא ניגשים ל DB בלולאה. לפני הפיתוח לתקף הנחות יסוד וארכיטקטורה, ואם צריך תייצר לצורך זה אבטיפוס. תימנע מ Join – ים רבים, גם אם זה אומר שצריך לעשות Denormalization ל DB. כל מה ששואלים עליו בכמויות גדולות, תדאג שיאונדקס. אל תשתמש ב PL/SQL כלוגיקה עיסקית ואל תכתוב שם קוד. אם אתה כותב קוד PL זה כנראה דבר רע. עדיף לשאול שאלה שמביאה Raw Data ואת העיבוד של הלוגיקה העיסקית לעשות בזכרון של המחשב, עם קוד בשפה נורמאלית שניתנת ל Debug ולניהול. עבודה עם ORM ועם אוביקטים, תמיד תהיה יותר קלה לכתיבה מאשר שימוש ב SQL עם שאילתות מורכבות וכתיבת לוגיקה תכנותית בשפה שאינה פרוצדורלית. לעבוד במנות גדולות יותר טוב מעבודה ברמת רשומה בודדת, גם אם הנצילות לא מלאה.
הוזכר גם נושא של מניעת נעילות ונעילה חכמה כגורם שמפריע למיקבול, וגם פיזור של תורים בין ספקים למשתמשים כאמצעי למנוע בעיית נעילה על התור. והודגש שצריך המון מחשבה על מה לנעול ומתי, כי זה גורם מגביל מספר אחד ליכולת המיקבול של המערכת.
כמובן שאת כל ההמלצות יש לקחת עם קורטוב של מלח, כי זה התאים לפרויקט הספציפי הזה, והכל תלוי גם בגודל ובביצועים הנדרשים. לקחתי משם כמה פנינים. האחד זה המונח "רוחב פס של קשית". והשני הוא הסיפור על המפתח שיושב על מכונה חזקה, והמשתמש בשטח יושב על גרוטאה, ומה שלוקח למפתח שניה על המחשב בשטח יכול להתבטא בדקות.
עוד דבר שאהבתי היה הנושא של תראו כמה ירוק יש כאן יחסית לכאן. ירוק הכוונה היא כמה הערות נכתבו כדי להסביר את הקוד, בשני המקרים (לפני התקון ואחרי התיקון). איזו תמימות נעורים יש במשפט הזה. כמה מפתחים באמת מתעדים נכון את מה שהם כותבים, אם לא יושב להם ראש צוות קשוח מעל הראש ומכריח אותם לעשות את זה. וכמה זה רחוק עדיין, מזה שהקוד אמור לתעד את עצמו.
בשלב הזה כולם הלכו לאכול ארוחת צהריים. אני בדרך כלל לא אוכל בצהריים אז התחברתי לרשת ועבדתי קצת.
לאחר ארוחת הצהריים היה פיצול נוסף ואנשי ה Java נפרדו מאנשי ה NET. והלכו לשמוע משי כהן מאורקל ישראל, מה מציעה אורקל בתחום. כאשר באותו זמן, אנשי ה DB, שמעו על ניתוחי ביצועים בזמן אמת, מליאור סבג מאורקל ישראל. לומר את האמת, אם הייתי פנוי, הייתי הולך לשמוע את שי, אבל מה לעשות, וזה היה חריץ הזמן שבו אני הרצתי על הנושא האהוב עלי Production Dbugging.
ההרצאה שלי היתה אותה הרצאה שהעברתי בארוע הזה לפני שנתיים, אבל מה לעשות, בכל שנה יש דור חדש שצריך לחנך אותו, על הדקויות של סביבת הייצור, ואיך לאסוף שם מידע. הקהל היה אקטיבי, היו המון שאלות והמון נקודות עניין, בקיצור כף.
לאח הפסקה קצרה עברתי לשמוע על מקרה נוסף של שיפור ביצועים בשטח, כאשר אני מוותר על מוטי באני ממיקרוסופט, שדיבר על הכלים של Sys Internals (שאותם אני כבר מכיר) ועל הרצאה על אופטימיזציות חדשות של אורקל 11g, שהעבירה גליה קוקה מאורקל ישראל.
הסתבר שהמערכת המדוברת מתבססת המון על Java Script, ואני חייב לומר מראש, ש Java Script זה לא היה אף פעם My Cup of tee. אבל מעניין אותי תמיד לשמוע על תקלות, בעיות, ובעיקר איך עלו עליהם, ואיך פתרו אותם. בהרצאה הוצגו הכלים FireBug ו IEDevTools שהם ספציפיים לדפדפן, ומאפשרים צפיה ב DOM, ביצוע Debug של Java Script, שינוי דינמי של Poperties וכו'. בהרצאה הוצגה דוגמא ספציפית איך שימוש בכלים הללו עזר לפתור בעיה. אחר כך הוצג Fiddler, עם בעיה אחרת ברמת התקשורת בין הדפדפן לשרת, שהוא סיע לפתור. ולסיום הוצג DynaTrace AJAX, עם דוגמאות לבעיות שנפתרו בעזרתו.
אם קודם סלדתי מכל שימוש ב Java Script, התחושה שלי רק התחזקה לאחר ההרצאה הזו. הבעיה היא, שכמו שזה נראה, כולנו נצטרך לסבול הרבה בעתיד מ Java Script, ככל שנתקדם יותר לכיוון של HTML5, ואני ממש לא אוהב את זה.
לסיום ויתרתי על הרצאתו של ולאד אזרקין ממיקרוסופט בנושא כלי תכנות מקבילי של NET. (מתנצל ולאד, בטח היה מעניין אבל זה נושא שאני כבר מכיר. ועל הרצאה נוספת שעסקב ב DB והצטרפתח להרצאה של ארכיטקט מערכת על ביצועים של מנועי חיפוש. הוצגו בהרצאה גם ההיסטוריה וגם האלגוריתמיקות השונות של מנועי חיפוש כולל המון שיקולי Scalability וטיפול בכמויות ענק של מחשבים והחיבור ביניהם. נקודת כניסה טובה למי שרוצה לחקור יותר היא מנוע החיפוש solr.
נכון שהמפגש היה לפני קרוב לשבוע, אבל מצד אחד היה לי על הראש את Juval, ומצד שני היו לי כמה פרויקטים להשלים, וחשבתי כבר לשכוח מכל העניין, אילולא טרח אורי ושם את ההקלטה של הארוע ברשת למי שמעוניין לשמוע.
אז לפני שאני מתחיל לשלוח אש וגופרית (ויש לי הרבה אש וגופרית), בואו ונתחיל עם הדברים החיוביים. קודם כל קבוצת ה Software Craftsmanship. היא אחת מהקבוצות החביבות והמוערכות ביותר אצלי ברשימת קבוצות המשתמשים שאני מבקר בהן (ומי שמכיר אותי, יודע, שאני משתדל לבוא למפגשים של כמעט כל קבוצת משתמשים שרק קיימת, כך שיש לי פרופורציות).
הסיבה שאני כל כך מעריך את הקבוצה הזו, היא שבקבוצה הזו, גם לפי שמה, וגם לפי חלק גדול מהנושאים שעולים במפגשים שלה, עוסקים בגורם מספר אחד, שאני נתקל בו, כאשר אני מנתח טעויות בקוד, במערכות מתמוטטות, והוא חוסר מקצוענות של המפתחים (וגם קצת למעלה מזה בשרשרת המזון).
חשוב לציין בנקודה הזו, שחוסר מקצוענות בכתיבת הקוד, לא מתחיל בדרך כלל מהמפתחים. זה מתחיל בראשי הצוותים, במנהלים של ראשי הצוותים, ובדרך כלל השרשרת ממשיכה עד ה CTO. כי אם מפתח רשם Try Catch ריק בקוד (סתם דוגמא), וראש הצוות לא גילה את זה, ו/או גילה את זה, אבל לא התיחס לזה בחריפות. והדרג שמעל ראש הצוות, לא גילה ועצר את התופעה בעודה באיבה, וכן הלאה. המפתח אשם, אבל האחריות היא גם (ואולי בעיקר) בדרג שמעליו. במערכת שמחפפת, המפתח לעולם לא ילמד לכתוב קוד נכון. לעומת זאת במערכת שמתפקדת נכון, אחרי הפעם הראשונה שהמפתח כתב Try Catch ריק, מובטח שהוא לא יחזור על הטעות הזו שוב.
ודרך אגב, מפתח שגילה Try Catch ריק בקוד, שלא הוא כתב, או שראה אותו, בזמן שהוא סרק קוד היסטורי, שקיבל לתחזוקה (או בספריה של Open Source), ולא הפך את זה מייד ל Item ברשימת ה Todo של הפרויקט, לא נקי מאשמה, בדיוק כמו זה שכתב את ה Try Catch הריק. ואם ראש הצוות שלו, ברגע שראה את זה ברשימת ה Todo של הפרויקט, לא הורה לו לתקן את זה בעדיפות ראשונה, ולא הגדיר מייד מטלה לכל המפתחים בצוות, לסרוק את הקוד, ולחפש עוד מקרים כאלה, ולטפל בהם מייד. לא צריך להתפלא, אם באותו פרויקט, קוראים לי מדי פעם, לטפל במערכת המתמוטטת, בכל פעם שהיא סוטה מנקודת הייציבות (הזמנית) שלה.
יש הרבה מה לומר על כתיבת קוד נכון, ואני חושב שזה נושא מספיק גדול ומכובד, שניתן לעסוק בו רבות. אורי חושב בגדול כמוני, אבל הוא לא רוצה להתמקד בקבוצה שלו רק בתחום ה"צר" הזה (שימו לב למרכאות), והוא מרחיב את תחומי העניין של הקבוצה לנושאים נוספים. אין לי בעיה עם זה, אבל ככל שהקבוצה מתרחקת מהנושא העיקרי (לטעמי האישי) של "מקצוענות המפתח" ו "מקצוענות כתיבת הקוד", אני תוהה ביני לבין עצמי, אם אין כאן איזה שהוא פיספוס.
אני מסתובב המון בארגונים שיש בהם מערכות מתמוטטות (לא סתם אני Bug Exterminator). אני נתקל שם בהרבה מפתחים שעושים טעויות ברמת הקוד הבסיסי. יש הרבה שלא מבינים אלף בית של ניהול זכרון בקוד מנוהל. יש הרבה שמשתמשים בפונקציות הלא נכונות, להשגת המטרות הלא נכונות (שימוש לא נכון ב API). אני כל פעם מורט מחדש את השערות (שאין לי), כשאני רואה קטעי קוד, שמתאימים לתיכוניסט שלמד זה עתה תכנות, ולא למפתח מקצועי, שאמור להתיחס לכתיבת קוד כ "תורתו אומנות", ושיש לו גאווה מקצועית, לא לעשות Check In, לקוד, שהוא יודע שיש בו בעיות.
אז מה היה לנו במפגש הנוכחי (מספר 9 לספירה הקבוצתית) ? היה לנו פנל שבו השתתפו רן תבורי, אלעד סופר וליאור שכטר. כל אחד מהם כבודו במקומו מונח, והם נושאים בתפקידים רמי מעלה, והמקצוענות שלהם אינה מוטלת לרגע בספק. ומי שחושב לרגע אחד שאני מתלוצץ או ציני בנקודה הזו, שיעקוב בבקשה אחר הקישורים מאחורי השמות, ויתרשם בעצמו, שאין כאן אפילו טיפה אחת של ציניות (בניגוד להרגלי).
אז איפה כל האש והגופרית ? לומר את האמת, האש והגופרית מכוונת כל פעם לנושא אחר, ולדובר אחר. כי כמו בכל פנל, היו דברים מענינים יותר, והיו דברים מענינים פחות (אותי). והיו דברים שהסכמתי איתם, והיו דברים שהעלו לי את הסעיף, ועליהם בעיקר אני הולך לכתוב כאן. אז נא לקחת את הכל בפרופורציות, כי אני מאד נזהר שלא לשפוך את התינוק ביחד עם המיים, ולכן גם כל ההקדמה הארוכה.
הנושא הראשון שעלה לי העצבים, היה בדיון על מה זה ארכיטקטורה, ומה עושים עם הייצור הזה, שנקרא ארכיטקט. ואני אומר כאן את הדעה הקטגורית שלי, שכל מערכת שאמורה להיפרס על מספר שרתים ו/או להיטמע ביותר מכמה תחנות קצה ו/או מכילה בתוכה יותר מכמה קומפוננטות שמדברות ביניהם (דהינו כל מערכת שאינה טרויאלית) זקוקה לארכיטקטורה, וזקוקה לארכיטקט. הארכיטקט צריך ללוות את הפרויקט במשרה חלקית או מלאה (או בכמה משרות, תלוי בגודל הפרויקט) לאורך כל חיי הפרויקט. כי הארכיטקט, הינו הגורם היחידי, שמסוגל לבצע את ה Decomposition של המערכת, ולהביא אותה לתחום, שבו האנרגיה לפתח ולתחזק אותה, היא המינימאלית.
יש הרבה ארכיטקטים רעים בשוק (ועל מנת להסיר ספק, אף אחד מחברי הפנל לא נמצא בקטגוריה הזו), יש הרבה ארכיטקטים שהיו מפתחים מעולים, וראשי צוותים נהדרים, ויש להם המון נסיון וידע. אבל הם חסרים או את ההדרכה, או את הידע, של מה זה בדיוק ארכיטקטורה, ומה בדיוק תפקידו של הארכיטקט בפרויקט. חלקם נמצאים כל כך למטה בקוד, שהם מפספסים את רמת האבסטרקציה הנדרשת מארכיטקט. הבעיה נובעת גם מזה שאין "בית ספר" ללימוד ארכיטקטורה, ולימוד מנסיון הוא תהליך איטי וכואב. מעטים הארכיטקטים שעברו הכשרה כשוליה אצל אומני ארכיטקטורה, עד שהבשילו להיות ארכיטקטים (והנושא של איך נוצר נגר אומן בימי הביניים, דווקא כן עלה בדיון).
זה שהיה למישהו נסיון רע עם ארכיטקטים לא מקצועיים (ושוב אנחנו חוזרים לנושא של מקצוענות), לא משנה את העובדה, שהארכיטקט והארכיטקטורה קריטיים להצלחת הפרויקט. ואני לא מקבל את הטיעון שהארכיטקט מבזבז את זמנם של המפתחים בזמן שהוא עושה את הארכיטקטורה. אני בדעה שלפני שלוקחים שישים מפתחים, ומתחילים לכתוב קוד של מוצר, במוד של Free Running (או Agile או Scrum), רצוי מאד שמישהו יראה את התמונה הכללית, יעבור על ה Use cases, יעשה את ה Decomposition, ויבנה ארכיטקטורה שתעמוד בפני כל שינוי שהמערכת אמורה לעבור בשנים הקרובות. כי אם לא תעשה את זה, תקבל מערכת, שעלויות הייצור והתחזוקה שלה, הן הרבה מעבר למתוכנן ולצפוי. וכן, עדיף שצוות של 60 מתכנתים ישב שלושה חודשים, ולא יעשה כלום בקוד של הפרויקט, אלא יקדיש את הזמן ללימוד של טכנולוגיות, וכלים, ו Coding Standards, בזמן שהארכיטקט יושב ועושה את ה Decomposition. במקום לרוץ לשום כיוון, ולקבל מהר הרבה קוד, שהדבר הנכון היחידי שצריך לעשות איתו, הוא לזרוק אותו לפח.
בהקשר הזה יודע כל מקצוען שמשחק בבורסה זה שעדיף למכור מניה בהפסד קטן מאשר להחזיק אותה ולהיגרר להפסד גדול. לעומת זאת הרבה פרויקטים יודעים היטב בעמקי הלב שאם היו נותנים להם להתחיל היום, הם היו עושים את זה יותר טוב ויותר מהר מאשר לנסות להוסיף Patch על Patch בתכנה הקיימת. ושלא יבין מישהו מזה שאני בדעה של לכתוב הכל מחדש כל פעם. אני בדעה שלא לכתוב קוד בכלל, אם אתה לא יודע בוודאות מה אתה צריך לכתוב, ובשביל זה צריך ארכיטקט.
לא, אני לא מסכים שהתכנה מובלת על ידי הקוד ואני לא מסכים שהארכיטקטורה היא נעלם בפרויקט כמו כל נעלם אחר. הרעיון של Proof of Concept מתגלגל, הוא משהו שאני לא מוכן לקבל באף פרויקט. כתיבת הקוד של התכנה צריכה להיות מובלת על ידי הארכיטקט. וכן, ברגע שיש ארכיטקטורה צריך לתעד אותה, בשפה שמובנת למפתחים, וצריך להצמד אליה, ולא לשנות אותה כל שבוע. כי אם אתה משנה אותה כל שבוע, זה סימן שלא בנית ארכיטקטורה שעמידה מספיק לשינויים בדרישות. ושלא נעשתה עבודת ארכיטקטורה נכונה בפרויקט.
למי שאולי מופתע לשמוע, יש כללים ל "מה זה ארכיטקטורה טובה", ו "מה זה ארכיטקטורה רעה", ואם עובדים נכון, ניתן לתקף ארכיטקטורה מול ה Use Cases ולמצוא בה טעיות ותקלות, עוד לפני שמוציאים אותה לאויר העולם. חשוב שהמפתחים יבינו את שפת הסימונים של הארכיטקט ויציתו לה. וחשוב שהארכיטקט יללוה את הפרויקט, ויוודא שמתכנתים חסרי נסיון לא יבזו את הארכיטקטורה שלו. ולא, תפקידו של הארכיטקט זה לא לשמור על השלמות הקונספטואלית של המוצר. התפקיד שלו זה לבצע Decomposition נכון, שיביא את המערכת לנקודת מינימום האנרגיה של הכתיבה והעמידות לשינויים. יש בארכיטקטורה המון נקודות של הנדסה, זה לא עניין לרגש ולתחושות וזה לא רק עניין של אומנות וטעם אישי.
טוב, הוצאתי מספיק אש וגופרית על הנושא הזה, ובואו נעבור לנושא הבא. הדיון על Scrum וכל שאר נושאי ה Agile למיניהם לא עניין אותי יותר מדי, כל טכניקה שתגרום למפתחים לכתוב קוד מקצועי ונכון טובה בעיני. שכל ישר תמיד חשוב. וכמו שאמר אחד המשתתפים (שהידע שלו ב Scrum רב משלי), ניתן להסביר מה זה Scrum בכמה שעות, ולא צריך הסמכה ו Certification בשביל להיות מומחה ומיישם של עקרונות של "שכל ישר". מה שחשוב זה התוצאה הסופית. קוד שעונה למפרט, ונכתב לפי כללי הארכיטקטורה שקבע הארכיטקט. כשאני למדתי "שכל ישר" בפרויקטים, קראו לזה (בעולם המיקרוסופט) MSF. היום כולם מכירים את זה כשבלונה של פרויקט ב TFS, שאף אחד לא יודע בדיוק איך משתמשים בה. אהבתי את הקטע של ה Least Capable Manager בתור מנהל האיטרציה, יש בזה הרבה חכמת חיים.
הנושא הבא שהעלה לי את הסעיף, היה הדיון באיך מוצאים מפתח טוב. מסתבר שלפחות לפי דעת חלק מהצוות, מפתח טוב צריך לדעת אלגוריתמיקה ברמה של איתור שורשי רקורסיה בקוד. להכיר לעומק חישובי סיבוכיות מתקדמים. ולא לשכוח שהוא חייב להיות ברמה של קוף, שיודע את כל סוגי האלגוריתמים לריצה על עצים, מכל צד לכל צד של העץ עם או בלי איסוף של פירות בדרך. וכמובן, שאם נותנים לו בעיה, הוא צריך לכתוב קוד פונקצינאלי עובד תוך שעה. והקוד שלו צריך להיות אלגנטי, יפה ועם פרוק פונקציונאלי נכון כי זה מה שחשוב. וכמעט שכחתי ידע בפרמוטציות ובקומבינטוריקה ועוד כמה דברים כאלה. לעומת זאת ידע ספציפי ב API, קיבל יחס של זילזול קל, לעומת הוד רממותה של מדע מבני הנתונים והרקורסיה.
בזמן שהנושא נידון העפתי מבט סביב וראיתי חלק מידידי הבוגרים יותר, עם פה פעור. מדובר באנשים שהם מפתחים מקצועיים, והקוד שלהם לא יבייש את שמה של קבוצת המשתמשים, אבל רובם לא יוכלו לשלוף לך מהשרוול את הסיבוכיות של כל אחד מהאלגוריתמים. ולמה שיעמיסו את זה על הראש שלהם ? בשביל מה יש Knuth ? אני לא מתבייש להודות, שגם אני הייתי נכשל בבחינה כזו של תכנות תיאורטי. אני בא לראיון לעבודה, לא לראיון למשרת דוקטור באקדמיה. אמנם רן ניסה להחזיר קצת דברים לפרופורציה, אבל הוא לא שבר מספיק חזק לטעמי.
אני אגיד לכם מה אני כן מחפש במתכנת טוב. קודם כל שיהיה בן אדם. תאמינו לי שבסולם הדרישות, זה אולי הדרישה החשובה ביותר. אחר כך, אני רוצה שיהיה איש צוות טוב, יקשיב לאחרים, יעזור לאחרים, יתפקד כחלק מהצוות ויתרום את חלקו למאמץ הצוותי. לגבי הכישורים המקצועיים שלו, התכונה שהכי חשובה לי, היא היכולת והרצון שלו ללמוד. אני מספיק זקן כדי לדעת, שאין כזה דבר מישהו שיודע הכל. וזה גם דרישה חסרת טעם כי טכנולוגיות הולכות ובאות וחוזרות כל כמה שנים. אם מפתח אומר לי, בראיון עבודה, כתשובה לשאלה ממוקדת, שהוא לא יודע נושא מסויים, אבל אם אני אתן לו מספיק זמן, הוא ילמד אותו וידע אותו על בוריו, אני מסמן לו פלוס. מכמה סיבות: א. בגלל שהוא לא מתבייש לומר שיש משהו שהוא לא יודע (ועוד בראיון עבודה), מה שאומר שאם אטיל עליו משימה שהוא לא מכיר, הוא ישאל שאלות, ויברר פרטים, ולא יעשה פרצוף שהוא יודע הכל, ואחר כך תגלה שהוא בכלל לא ידע על מה אתה מדבר ועשה שטויות. ו ב. הוא מוכן ללמוד מה שצריך, על מנת להצטרף לצוות. הדבר החשוב הבא שהייתי שואל את המועמד, זה איך הוא מתעדכן בתחום המקצועי שלו. איזה ספרים טכניים מעניינים קרא בשנה האחרונה, איזה מאמרים טכניים, איזה טכנולוגיות חדשות הוא למד. מפתח טוב (כמו רופא טוב) צריך להתעדכן כל הזמן (וזה גם נאמר על ידי אחד המשתתפים בפנל, רק בטון שקט מדי לטעמי).
הדבר האחרון שאני מחפש במתכנת זה שיהיה גאון משוגע, שהוא המקצוען הכי טוב שקיים בתחום, אבל אי אפשר לעבוד איתו בצוות, והוא הופך להיות צוואר הבקבוק בכל בעיה. וברגע שדורס אותו אוטובוס (או שהוא עוזב למקום אחר שבו יותר קל לו להתעלל בכולם) הפרויקט כולו נתקע לכמה חודשים, כי אף אחד לא מסוגל להבין את הגאוניות של הקוד שהוא כתב. וכן, מפתח שדוחה מראש את הרעיון שאחד מתפקידיו הוא לתחזק קוד קיים, לעשות לו Refactoring ולשפר אותו, ולא רואה בזה עבודה "מכובדת", יעוף גם אצלי מהראיון, עם הערה על "חוסר בגרות". כי כפי שאמר אחד מהמשתתפים בפנל, אין כזה דבר קוד חדש, או שאתה עושה Copy Paste, או שאתה משתמשי בספריה שמישהו אחר כתב, לא ממציאים היום את הגלגל מחדש, זה יקר מדי.
כתיבת קוד אלגנטי וידע תיאורטי, כל איש טכני טוב, עם מספיק ידע במדעים הריאליים, יוכל להשלים במידת הצורך. להיות בן אדם, זה תהליך הרבה יותר מורכב, שלא תמיד ניתן לבצע אותו אצל המועמד, כי זה דורש בדרך כלל ענווה, צניעות, ומה שאולי יותר חשוב, הכרה בבורות שלך. אני מצפה שלמועמד תהיה הכרות טובה של ה API הרלוונטי למערכת שאותה אני מפתח. והכרות טובה עם ה Caveats וה Pit Falls של כל אחד מקריאות ה API (ואם לא ב API שבו אני מפתח, אז אני בודק אותו בכל API שהוא מכיר, כי גם את הפער ידע הזה, ניתן לתקן). כל זה, לטעמי, הרבה יותר חשוב, ממבני נתונים או שורשי רקורסיה. ואם כבר מזכירים רקורסיה, כפי שהתבטא אחד המשתתפים בפנל, רקורסיה כמעט תמיד, זה דבר רע, בפרויקטים מהעולם האמיתי (הוא היה יותר חריף, והשתמש בביטוי לערוף את הראש של המפתח שמציע את זה), אז למה לבחון את הבנאדם במשהו, שיש סיכוי טוב שהוא לעולם לא יצטרך לממש בפרויקט ?
לאתר מתכנתים טובים מאד קשה גם ככה, אז למה לפספס הרבה אנשים טובים שרק דורשים קצת לימוד ? אני חושב שהגרלה אקראית של קורות החיים, כבר נותנת תוצאות טובות יותר. ולא, אני לא מסכים שלהסתכל על הקוד, יותר חשוב מקורות חיים. קורות חיים יותר חשובים בהרבה, כי מקורות חיים אני יכול להתקשר למנהל הקודם של אותו מועמד, ואם הוא מישהו שאני מכיר, תוך שניה יש לי תשובה אם לקחת אותו או לא. ואם אני לא מכיר את אותו מנהל ספציפי, אני כבר מספיק זקן כדי להבין בין המילים שהוא יאמר לי, מה הוא בעצם רוצה לומר.
בעניין ה Unit Tests וכו', הקשבתי לדיון התיאורטי, וקפץ לי לראש אחד הלקוחות שלי, שנאבק נואשות בהנהלה שלו, על מנת שיקצו לו עוד איש QA אחד טוב (יש לו רק אחד בצוות של חמישה מתכנתים). אותו ראש צוות, קיטר בפני, שהרבה יותר קל לו מול ההנהלה לקבל מתכנת נוסף לצוות, ולא איש QA, כי איש QA הוא תקורה על הפרויקט. לך תסביר להנהלה המטומטמת, שאיש QA טוב, חוסך המון זמן (וכסף) לצוות הפרויקט, ועוד יותר המון זמן (וכסף) ללקוחות בשטח, בגלל ה "תקורה" שלו. ולך ותסביר להם, שבפרויקט, לקראת שלבי ההגשה שלו, המספר הנכון הוא לפחות שני אנשי QA, על כל מפתח (וגם זה לא תמיד עוזר).
בשביל לבדוק תכנה כפי שצריך, אתה צריך מישהו שהמומחיות שלו זה בדיקות תכנה ולא פיתוח. כי בודק תכנה טוב, חושב אחרת ממפתח. בודק תכנה טוב, יודע לתכנת הרבה יותר טוב ממפתח ממוצע, אבל הפוקוס שלו שונה., הוא נהנה לבדוק את מגבלות המערכת, ואיפה הוא יכול להעיף את הקוד, ופחות מעניין אותו, איך הוא יכול לממש את ה Feature הספציפי שכתוב במפרט. כמוובן שבודק תכנה טוב, יעשה כל מה שביכולתו, על מנת שהבדיקות יהיו אוטומטיות ולא ידניות. זה כל כך ברור שככה צריך לעבוד, שאני לא מבין איך אני עדיין צריך להסביר למנהלי פרויקטי פיתוח, שזו הדרך היחידה לעבוד. וכן, כל פעם שמוצאים Bug יש להכין Script שמשחזר אותו, ולהוסיף אותו לבדיקות האוטומטיות של המערכת, ולו רק כדי להבטיח, שאם אחד התיקונים הבאים יחזיר את ה Bug הזה, הוא ימצא ב Build היומי, ולא אצל הלקוח בשטח (ואני כמובן לא מדבר פה על מקרה ספציפי, שקרה לי ממש בשבוע האחרון, אצל לקוח).
הקטע האחרון שהעלה לי את הסעיף, היה הקיטורים על זה ששימוש ב Agile ו Scrum וכל שאר הזימזומילים האלה, גורם לכך, שקשה למפתח לקבל קרדיטים על העבודה שלו, ולהתפתח בארגון, כי הכל הופך לעבודה קבוצתית, כולל ההחלטה אם הוא רוצה ללמוד לפתח את עצמו מקצועית.
אז לתשומת לך כל המקטרים. האחריות על ההתפתחות המקצועית שלכם היא רק עליכם, ולא על אף אחד אחר. אני מרחם על כל המפתחים, שעוברים ממקום למקום, בגלל תוספת של 1000 ש"ח לברוטו. אתה צריך לעבור ממקום למקום, אך ורק לפי הקריטריון של איך זה מקדם את הידע המקצועי שלך, ואת הקריירה המקצועית שלך. כי אחרת, תגלה מהר מאד, שבמקום להנות מהמקצוע שלך, אתה נשחק ממנו, והדרך משם לאשרם בהודו, או לתיקון שלטי רחוב, קצרה הרבה יותר ממה שאתה חושב. סיפוק מקצועי לטווח רחוק, משמעותית הרבה יותר תורם לאיכות החיים שלך, מאשר עוד 1000 ש"ח במשכורת. אבל צריך קצת נסיון חיים כדי להבין את זה, וזה חסר להרבה מפתחים צעירים שיוצאים מהאקדמיה, או מהיחידה המקצועית המובחרת בצבא, ורואים רק את קצה האף של ההזנק הבא שלהם, ולפעמים אפילו לא רואים ממטר, את ההזנק הנוכחי שלהם.
מה עוד אהבתי, את המשפט "היום הייתי מאד יעיל, מחקתי 1000 שורות קוד מיותר" (בהקשר של איתור שיכפול קוד מיותר ובכלל). את הדיון על זה ש Performance זה לא באמת דבר כל כך חשוב (ויש לי הרבה מה לומר על הפיקסציה של כולם לשיפורי Performance מיותרים), וגם אהבתי את ההערה הסופר צינית (וכמה היא נכונה) שככל שאתה בחברה יותר גדולה, ככה אתה כותב פחות שורות קוד ליום.
מרתק כמה דברים שקשורים לתהליך עלו במפגש הזה בלי להרגיש. הרבה מהנפילות וההתמוטטויות שאני מטפל בהן מקושרות ישירות לטעויות בתהליך. והסיבה שאני מדגיש את זה בא כדי להבהיר שיש קשר ישיר בין נפילות מערכת לטעויות ב Process ומזה בדיוק בא החלק השני של תחום הפעילות שלי שרשום בכרטיס הביקור, Process Plumber (ולא כפי שטועים רבים לחשוב, שזה קשור ל Process & Threads).
משוב יתקבל בברכה, גם מחברי הפנל, גם ממי שהיה שם, וגם מכל אחד אחר שיש לו מה לומר בנושא הזה. טל"ח.