הקושחה הראשונה: המקום שבו טעויות קטנות הופכות יקרות

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

טעות 1: אין נתיב עדכון מהיום הראשון

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

טעות 2: בלי Watchdog ומנגנוני התאוששות

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

טעות 3: ארכיטקטורה חוסמת

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

טעות 4: אין לוגים ואין יכולת אבחון

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

ועוד שלוש שמתגלות רק בייצור

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

איך נמנעים מראש

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.