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