פיתוח תוכנה VS טיפוח תוכנה

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

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

דרושים: אנשי תחזוקה

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

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

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

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

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

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

עקרון הרצף

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

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

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

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

2 מחשבות על “פיתוח תוכנה VS טיפוח תוכנה

  1. פינגבק: איך להחזיר חוב (טכנולוגי) | אותיות ומספרים

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s