#12 לרבע את המעגל

מהי פסגת החלומות של כל מנהל פיתוח? מה זה "פורטינג" ולמה זה מעצבן? ואיך קרה שקנגורו ירה טיל סטינגר

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

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

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

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

כמעט אותו קוד. כי במהלך הפיתוח היה צורך לעשות התאמות קלות וכמה שיפצורים בקוד הישן על מנת לעמוד בדרישות החדשות. אז הצוות החליף את ספריית הקריפטו, כי היא כבר הייתה ישנה מדי, וגם קבצי האתחול עברו עריכה מסויימת (כלומר נמחקו ונכתבו מחדש) וכמובן שעוד כמה שינויים נקודתיים פה ושם כדי לגרום למערכת לרוץ יותר מהר וללא נפילות. בסוף כאשר משווים את הקוד של המוצר החדש לזה של המוצר המקורי מגלים שרק 3.5% מהקוד זהה וכל השאר נכתב מחדש, אבל מה זה משנה, העיקר שעשינו Re-use. אני חושב שבעברית יותר מתאים לקרוא ל Re-use מיחזור (Recycle בלע"ז) מאשר שימוש חוזר. שימוש חוזר נשמע כאילו שוב משתמשים בדבר כמו שהוא ללא שינוי, כמו סוללות נטענות. אבל מיחזור מוגדר כך: "מיחזור הנו פירוק מוצרים וחומרים שונים לכדי חומרי גלם למיניהם. מחומרי גלם אלו, ניתן ליצור ולפתח מגוון של מוצרים, בהתאם לחומר המפורק", כאשר בעיני הדגש הוא על המילה פירוק. בא נפרק את מה שעשינו ונבנה את זה מחדש, אבל יותר טוב. כי מהניסיון שלי כשעושים Re-use, נראה שבעיקר עושים שימוש חוזר בדברים הרעים, ודווקא את הדברים הטובים לא משמרים.

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

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

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

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

והמהנדס החכם אומר: אין באמת דבר כזה קוד Re-use, יש רק Fake-use