מה יותר חשוב: הפיתוח או הבדיקות? מהי סרבנות בדיקות אידיאולוגית? מתי בכלל מריצים Unit-Testing? ו… איזה ביטוי עברי הסתתר בפוסט?
אחרי יותר משלושים פינות, הרגשתי בשל מספיק לכתוב על אזור הדמדומים של ההיי-טק, המערב הפרוע של עולם התוכנה – ה Unit-Testing, או בעברית פשוטה, הבדיקות אותם אמור מפתח הקוד לבצע בעצמו.
אבל נפתח בסיפור קצר. לפני כשבועיים יצא לי לשלוח מכתב. כן מכתב אמיתי עם מעטפה ובול. אני כבר לא זוכר מתי פעם אחרונה שלחתי מכתב. לדואר אני מגיע רק כדי לקחת חבילות. כשהגיע התור שלי אמרתי לפקיד שאני צריך לשלוח מכתב בדואר רשום, הוא מיד שאל אותי: "הבאת מעטפה ובול?". אני לא רגיל להישאר בלי מילים, אבל השאלה הזו באמת תפסה אותי לא מוכן. בשביל מה הגעתי לדואר אם לא בשביל לקנות מעטפה ובול? כשהתאוששתי הבנתי שחייב לצאת מזה איזה פוסט. אני לא אתן לסיפור כזה לחמוק ממני, זו ממש הרמה להנחתה. עכשיו רק צריך לחבר את זה איכשהו לעבודה בהייטק. כבר נמצא משהו.
אז מצאתי. בערך. כבר יצא לי לכתוב מספר פעמים על יחסי האהבה-שנאה שיש בין קבוצות שונות בעולם ההיי-טק, בעיקר בין קבוצות הפיתוח והבדיקות, למשל בפוסט הזה, אבל לא רק. המאבקים הקשים ביותר הם כמובן על תחומי האחריות של כל קבוצה. אבל בניגוד גמור לכל ארגון נורמלי, בו כל קבוצה שואפת לכמה שיותר אחריות, בעולם הייטק המצב בדיוק הפוך. כל קבוצה רק מנסה להקטין את תחומי האחריות שלה, ובעיקר להעביר את האחריות לקבוצה אחרת, בדיוק כמו הבחור מהדואר.
בכל פעם שאנשי הבדיקות מוצאים באג מתחיל טורניר הפינג-פונג המסורתי בינם לבין אנשי הפיתוח. זה כן משתחזר, זה לא משתחזר. עשית Reset או לא עשית? וכמובן שאלת מיליון הדולר: מי אמר שאנחנו בכלל צריכים לתמוך בתרחיש הזה. גם כשכבר סוף סוף ניתן גזר הדין, על פי רוב אחרי שהתמלאה מכסת הצעקות ומוכרז קבל עם ועדה שהתופעה המוזרה היא אכן באג חוקי, אזי מתחיל קרב איתנים בין קבוצות הפיתוח השונות איזו קבוצה אחראית לחקור ולתקן את הבאג.
לפעמים אני אומר לעצמי איזה מזל שאנחנו לא רופאים. נשברה לך היד? בא ננסה לעקם גם את היד השניה באותו אופן ונראה מה קורה. התינוק לא יוצא? את בטוחה שהוא אמור בכלל לצאת מהצד הזה? אם אין דופק, אז בא ניתן מכת חשמל ונראה מה קורה. קשה לך לנשום? תמתין בטריאג' עד שהקרדיולוג יתפנה. בקיצור אנחנו, ובעיקר המנהלים שבינינו, עסוקים בלברוח מאחריות. לא במקרה המילה אחריות נגזרת מאותו השורש של המילה אחר. זו אחריות של מישהו אחר, זה לא אני זה פופטיץ.
אז כמו בכל ארגון בריא, או לפחות בארגון שחושב שהוא בריא, כשיש מאבקים פנימיים קודם כל מגדירים גבולות גזרה ברורים. עד כאן אני ומכאן אתה. הפרדת רשויות. אבל כשהגיעה מועצת גדולי ההיי-טק לשרטט את קו הגבול בין קבוצות הבדיקות לפיתוח היא נתקלה בבעיה. כל צד ניסה להעביר את האחריות לצד השני. אנשי הפיתוח התחפרו מאחורי קו מז'ינו של "מה לא מספיק שזה מתקמפל?" ואילו אנשי הבדיקות לא הסכימו לקבל קוד שלא נבדק לפני ולפנים. בקיצור, חפשו לכם פראייר אחר.
הפשרה כמובן הייתה ליצור שטח הפקר בין שתי הקבוצות המכונה Unit-testing. כלומר, אנשי הפיתוח יוותרו קמעה, ויואילו בטובם להריץ כמה בדיקות בסיסיות לוודא שהכל בסדר וששום דבר לא נשבר. רק אז יהיה מותר לעשות צ'ק-אין לקוד, והאחריות תעבור לאנשי הבדיקות, שיצאו עם חצי תאוותם בידם.
לכאורה פשרה מושלמת, כל צד ויתר קצת, ויאללה לעבודה. אלא שכמו בכל שטח הפקר, מהר מאוד החלה ההפקרות לחגוג. אך אחד לא ידע להגיד בדיוק מה זו החיה הזאת Unit-Testing. מה הוא כולל וכמה זמן צריך להשקיע בו. ומהכרות מעמיקה עם אופיים של אנשי הפיתוח, משימת הרצת ה Unit-Testing, היא ממש כמו לתת לחתול לשמור על השמנת. איזה אינטרס יש למפתחים להשקיע בבדיקות כאשר הם יודעים שבכל מקרה יש קבוצה שלמה של אנשי בדיקות שבכל מקרה הולכת לקרוע את הצורה לתוכנה? בשביל מה לטרוח אם יש מי שיעשה את העבודה במקומי?
כמובן שאי אפשר להגיד את זה בקול, אחרת אנשי הבדיקות יתעצבנו. אז מה עושים? אומרים שהרצנו Unit-Testing. הרי אף אחד לא באמת יכול לדעת שלא בדקתי כלום. כדי לא לצאת לגמרי שקרנים אז כן מריצים פעם פעמיים את התוכנה, רואים ששום דבר רע לא קרה, ויאללה צ'ק אין. למעשה, לשאול איש פיתוח אם הוא הריץ Unit-testing זו שאלת קיטבג הפוכה. בדיוק כמו השאלה "ארזת לבד?" בשדה התעופה. מישהו פעם ענה שהוא לא ארז לבד? ראיתם פעם פראייר כזה? בדיוק אותו דבר לגבי ה Unit-testing. בוודאי שבדקנו! ועוד איך בדקנו! הרצנו את כל Unit-Test מספר 17, ועוד לגמרי לבד.
התגובה לא איחרה לבוא. הומצאו כל מיני שיטות ומתודולוגיות עם שמות מפוצצים שכל מטרתן הייתה לאלץ את אנשי הפיתוח לבדוק בעצמם את הקוד, אבל כולן העלו חרס. אציין את אחת המתודולוגיות החביבות עלי במיוחד, ה TDD, שזה Test Driven Development, כלומר פיתוח מונחה בדיקות. זהו רעיון גאוני עם שם מפוצץ שבמרכזו עומד עיקרון ההיפוך. כלומר אנחנו לא מריצים בדיקות בשביל לבדוק את המוצר, אנחנו מפתחים את המוצר בשביל שנוכל להריץ בדיקות. איך לא חשבו על זה קודם?! סוף סוף אנחנו יודעים מה באמת עיקר ומה טפל.
כמו בכל כלל, גם כאן יש יוצאים מן הכלל. בכל קבוצת פיתוח ישנו איזה צדיק או צדיקה בסדום שאשכרה ממש בודקים את הקוד שלו לפני שהם עושים צ'ק אין. לא סתם התרגום לעברית של Unit-Testing הוא בדיקות-יחידה, בגלל שבין כל עשרות המפתחים בקבוצה, יש רק מפתחת יחידה שבאמת מריצה את הבדיקות.
אבל מפתחים אלו הם באמת בודדים, מוקפים בים של מפתחים סרבני בדיקות. חשוב להבין שהסרבנות הזו אינה נובעת מעצלנות או חוסר זמן. זוהי סרבנות בדיקות אידיאולוגית. אז לכל חברי (לשעבר?) אנשי הבדיקות, תדעו לכם שהסיבה שאנחנו מסרבים להריץ Unit-Testing, היא רק בגלל שאנחנו חושבים עליכם. היינו מתים להריץ בדיקות בעצמנו, אבל אם אנחנו נריץ את הבדיקות, מה אתם תעשו?
והמהנדס החכם אומר: ואני חשבתי ש Unitesting מריצים רק בחודש יוני
פינת הקפה 
עושה רושם שלפיתוח מאוד נוח שקיים קיו איי כדי שיהיה שעיר לעזאזל במקרים של בעיות בפרודקשן.
חוץ מזה אני לא מסכים שמהמסקנות אליהן הגעת בפוסט נכונות.
לדעתי האחריות לתקינות של הקוד צריכה להיות של המפתח, וכל ניסיון אחר יסתיים בלולאה של חוסר תפקוד כפי שתיארת.
בהגדרת גבולות הגזרה לקיו אי לא צריכה להיות שום אחריות לתקינות הקוד. הקיו אי לא צריך להיות אחראי למתן אישור שקיימת עמידה בדרישות שהמפתח קיבל.
כל בדיקה אוטומטית צריכה להיכתב ע"י המפתח.
אם המפתח מחליט להכניס בדיקה אוטומטית ברמת בדיקת יחידה, או בדיקת ממשק משתמש, זאת החלטה שלו. הוא ומי שעשה לו קוד ריוויו צריכים לשאת באחריות על כל בעיה בקוד כולל בעיות רגרסיה שנגרמו כתוצאה מהשינוי.
אהבתיאהבתי