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

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

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

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

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

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

הבעיה המרכזית היא שבדרך כלל לא מלמדים תכנתים להתמודד עם כל זה. ולכן קיים פחד שמסביר את הרטעה מלעסוק בנושא. התחום גם נחשב כלא סקסי ולכן לא משך את מיטב הכשרונות. אבל יש גם מי שניסו, הצליחו ואפילו כתבו את הספר שנחשב התנך של התחום Working Effectively with Legacy Code

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

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

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

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