האתר הישראלי להנדסת תכנה

תכן מערכות בטוחות

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

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

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

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

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