קוד הוא אחריות הארגון כולו – לא רק המפתחים

מאת: יובל צוק

מדי שבוע מתפרסמות חדשות על פרויקטים בעלויות של מיליוני דולרים שירדו לטמיון (במקרה הטוב) או על פגיעה בביטחונם או בבריאותם של משתמשי-קצה (במקרה הגרוע) – וזאת עקב בעיות באיכות הקוד. רק ברבעון האחרון של 2013 מיזם הבריאות של ממשל אובמה, HealthCare.gov, זכה לשיעורי רישום נמוכים ביותר בשל באגים באתר. בצרפת, באגים בפרויקט התשלומים הממוחשב לאנשי צבא גרמו לתשלומים שגויים, והוא נסגר על-ידי הממשלה לאחר שהושקעו בו יותר מ-500 מיליון אירו.

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

באופן אירוני, דווקא המרוץ נגד השעון להיות ראשון בשוק ולצאת עם עדכוני גרסאות ברמה יומיומית – הוא זה המוביל ארגונים לבעיות איכות, בעיקר באגים – כאלה הגורמים לעיכובים ביציאה לשוק או ל"פדיחות" יחצניות לאחר שחרור גרסה בעייתית. שינויי קוד רבים, הנעשים תחת לחץ של זמן וללא כל בקרה על מצב הקוד (באמצעות Automated Unit Tests, לדוגמה) – הופכים את תהליך הפיתוח ל"מערב הפרוע של ההיי-טק" ואת הקוד היקר ל- Legacy Code: באגים מוכנסים לקוד, שפעם עבד כראוי, מחלקות ה-QA לא מסוגלות "לנקות" כמויות של קוד באופן ידני או חצי-אוטומטי, המפתחים עוברים מפרויקט לפרויקט ולא תמיד זוכרים מה פיתחו לפני חודש או חודשיים. כל אלה מובילים לעיכובים בהשקות מוצר (שוב, במקרה הטוב), או לפדיחות ארגוניות במידה והמוצר הגיע פגום למשתמש הקצה (במקרה הרע).

מחקר אחרון של CapGemini מצא כי תקציב ה-QA  גוזל כ-25% מכלל תקציב הפיתוח, אך הבדיקות שנערכות ב-45% מהארגונים עדיין אינן אפקטיביות דיין, בשל התחלתן מאוחר מדי: לאחר סיום שלב פיתוח הקוד. הגרף הידוע של קייפר ג'ונס "the cost of bugs" תומך גם הוא במה שהוכח לפני שנים: עלות תיקון באג שנתפס מוקדם בתהליך כתיבת הקוד זולה משמעותית מעלות תיקונו מאוחר יותר.

משיחות שערכנו עם לקוחות בשנה האחרונה, וכן עם אנליסטים מחברות מחקר מובילות, אני צופה התחזקות בשימוש ב-Developer Testing, ובעיקר ב-Automated Unit Testing – שיטות שהוכחו כיעילות ביותר (מבחינת עלות-תועלת) למניעת בעיות של איכות קוד לאורך כל חיי המוצר. מעבר להיותו קו מנחה במתודולוגיות אג'יליות, תהליך הבדיקות שעושה המפתח בזמן הפיתוח (Developer Testing) מתאים ויעיל לכל שיטות הפיתוח, וזאת בשל יתרונו הגדול להבטיח – לאורך שנים – את איכות הקוד, ניקיונו, ומניעת שבירתו בעת הכנסת שינויים עתידיים, מה שמקצר משמעותית תהליכי פיתוח ובדיקות לאורך כל ה-ALM.

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

יובל צוק הוא מנכ"ל חברת טייפמוק, המתמחה בפתרונות Automated Unit Testing Solutions, המאפשרים שמירה על קוד נקי ואג'ילי לאורך כל חיי המוצר, מונעים היווצרות legacy code ומצמצמים הכנסת באגים לקוד עובד. בקרוב תצא חברת טייפמוק עם פתרון ארגוני fully automated לבעיית איכות קוד -(Typemock LCQ (Lifetime Code Quality.