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