כשעבדתי על פרויקט: 'אסור לנו לפחד להתחיל מחדש' – ראיון עם David Markesic, מהנדס תוכנה מוטמע בכיר

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

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

Marija Jurina: שלום David, נהדר שאתה משתף ידע וניסיון. בתור התחלה, כמה זמן אתה עובד כמהנדס Embedded ואיך הגעת לתחום הזה של IT?

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

אני מבין שבאחד מהפרויקטים הקודמים שלך נתקלת באתגר מעניין של תקשורת בין מודם 3G למיקרו-בקר (MCU). כדי לשתף דוגמה מהחיים האמיתיים, תוכל להרחיב מה היה הרעיון הראשוני והצורך במקרה זה?

כן, אשמח להרחיב. הרעיון הראשוני היה להשתמש במודם 3G כמקור להערה (wake-up) עבור ה-MCU דרך האינטרנט. להרחבה קצרה – המודם 3G היה צריך לשמור על החיבור לאינטרנט פעיל בעוד ה-MCU היה במצב כבוי, ולהעיר את ה-MCU רק במקרה של שגיאת חיבור או בקשת wake-up. הסיבה לכך נעוצה בעובדה שהיינו צריכים לצמצם את צריכת הסוללה כאשר המכשיר היה כבוי. ה-MCU שימש רק כדי להגדיר את חיבור האינטרנט ברשת הסלולרית ואת החיבור לשרת ששימש לבקשות wake-up. התקשורת (הגדרה וחילופי נתונים) בוצעה באמצעות פקודות AT. לצורך הגדרה נכונה של המודם 3G, שתכסה את כל תרחישי השימוש, נדרשו רצפי הגדרה מורכבים למדי עם החלטות רבות ושונות המבוססות על תגובות המודם 3G. לפיכך, הוטל עליי ליצור מנתח (parser) מתאים לפקודות AT שיוכל להתמודד עם כל המורכבויות של תרחיש השימוש.

מה היה נדרש כדי לפשט את קבלת ההחלטות על בסיס התגובות ממודם 3G?

תקשורת מודם 3G בוצעה דרך UART באמצעות פקודות AT. כדי להגדיר כראוי את מודם ה-3G לשמירה על חיבור אינטרנט אמין, המנתח היה צריך להתמודד עם רצפים מורכבים של פקודות AT שהיה צורך לשלוח, לקבל ולעבד. במקרה זה, התגובה הייתה מחרוזות שהכילו שילוב של מחרוזות ומספרים. לפיכך, המנתח שפיתחתי היה צריך למלא תפקיד כפול – מחד, הוא היה צריך להיות מסוגל לנתח את המספרים במחרוזות למספרים מקוריים (integers), ומאידך, להיות מסוגל לבצע חילוץ מחרוזות מהתגובות.

מה היה ייחודי בארכיטקטורה של המנתח שפיתחתם?

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

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

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

מה היה הגורם שגזל את מרב הזמן בתהליך מציאת הפתרון?

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

מה היה יכול לעזור מוקדם יותר בתהליך הפיתוח כדי לזרז את הדברים?

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

תודה על השיחה והשיתוף! אם יכולת לתת עצה אחת לעמיתיך המפתחים כיצד למצוא פתרונות בקלות רבה יותר, מה היא תהיה?

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

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

מחפשים הזדמנויות קריירה חדשות? עיינו ב- משרות פתוחות בקרואטיה!

שאלות נפוצות