טיפים לתכנות זמן אמת: הרצת בדיקות קריטיות בעליית האפליקציה

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

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

גרסאות מערכת ההפעלה או ספריית ה־C, שכן התוכנה עשויה להיות מותאמת לגרסאות מסוימות שלהן.

זמינות וגרסה של תיקון זמן האמת, שכן התוכנה עשויה לדרוש יכולות זמן אמת.

דיוק שעון זמן האמת של המערכת, שכן התוכנה עשויה לדרוש זמינות של שעון מערכת מדויק.

המשתמש שתחתיו רצה התוכנה, שכן התוכנה עשויה לדרוש הרשאה מיוחדת או משתמש מסוים בשלב כלשהו של ריצתה.

זמינות שטח דיסק פנוי, שכן התוכנה עשויה לדרוש שטח דיסק מסוים.

זמינות זיכרון פנוי, שכן התוכנה עשויה לרוץ בטעות על מערכת עם פחות מהכמות הנדרשת.

מופע קודם שרץ של אותה תוכנה או של תוכנה אחרת שעלול להפריע לפעולת התוכנה.

זמינותם של APIים מסוימים של הקרנל או של מודולי קרנל מסוימים הנדרשים לפעולה.

זמינותם של התקנים מסוימים (קבצי /dev) יחד עם הרשאה לגשת אליהם.

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

אתם עלולים לפספס הדפסות שגיאה מהאפליקציה שלכם ולכן להתרוצץ בניסיון למצוא שגיאות בכל המקומות הלא נכונים.

אתם רוצים שהשגיאות יופיעו מוקדם, וכל דבר שאפשר לגרום לו להופיע מוקדם — כדאי שיופיע מוקדם.

ראיתי את ביטחונם של מתכנתים בחומרה / במערכת ההפעלה / בסביבה שלהם מתנפץ יותר מדי פעמים ומוביל לשעות אינסופיות של מאמץ מבוזבז שאפשר היה למנוע באמצעות אסטרטגיה זו.

חלק מהדרישות הן מסוג להיות או לחדול, ובאמת אין לכם מה להמשיך לרוץ בלעדיהן.

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

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

עיקרון זה חשוב במיוחד למתכנתי מערכות זמן אמת ומערכות משובצות בשל כמה גורמים:

מערכות זמן אמת ומערכות משובצות קשות יותר לניפוי באגים ולניטור.

במערכות זמן אמת ובמערכות משובצות יש פחות כלים המאפשרים לאתר באגים.

אפליקציות זמן אמת ואפליקציות משובצות רגישות הרבה יותר מסוגים אחרים של אפליקציות לשינויים שונים בסביבה.

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

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