2.5. האם אתם מתקנים באגים לפני כתיבת קוד חדש?

• הגרסה הראשונה של Word for Windows נחשבה פרוייקט "מצעד המוות".
  
  • הוא לקח נצח.
  • הוא נדחה עוד ועוד.
  • הקבוצה כולה עבדה שעות מטורפות והפרויקט נדחה שוב ושוב והלחץ היה נוראי.
  • כאשר הדבר הארור נגמר שנים מאוחר יותר, מיקרוסופט שלחה את כל הקבוצה לנופש בקאנקון, וישבה לעשות חשבון נפש רציני.
• מה שהסתבר היה, שמנהלי הפרויקטים לחצו כל כך לשמור על לוח הזמנים, והמתכנתים פשוט מיהרו ופיתחו קוד גרוע במיוחד, מכיוון שתיקון באגים לא היה חלק מלוח הזמנים הרשמי.
• הסיפור מספר על מתכנת אחד, שהיה צריך לכתוב פונקציה לחשב את גובהה של שורת טקסט, וכתב בפשטות ";return 12" וחיכה לדיווח באג.
• בניתוח לאחר המוות, קראו לכך "מתודולוגיית אינסוף באגים".
• כדי לתקן בעיה זו, מיקרוסופט אימצה שיטה הקרויה "מתודולוגית אפס באגים".
  
  • "אפס באגים" משמעו שבכל נקודת זמן, העדיפות הגבוה ביותר היא לתקן באגים לפני שכותבים קוד חדש.
• באופן כללי, ככל שמחכים יותר זמן לפני שמתקנים באג, העלות (בזמן וכסף) לתקנו גבוהה יותר.

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

Written by Shlomi Fish