3 טיפים של Git לשיפור תוכנת מכשיר רפואי

פרסומת
X-ray_Promo1


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

פרסומת

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

אתה צריך להשקיע קצת זמן כדי ליצור מודל נפשי משלך לאופן שבו Git עובד כדי להפיק ממנו את המרב. בואו נצלול לשלושה מימושים מאירי עיניים שעוזרים לי להשתמש ב-Git טוב יותר.

  1. אתה לא צריך להתחייב על הכל!

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

נניח שאתה נסחף בתכנות וביצעת כמה שינויים לא קשורים מבלי לבצע אף אחד מהם. מה אתה עושה? Git מפריד בין "עותק העבודה" – שבו נמצאים כל השינויים המקומיים והבלתי מחויבים – לבין "אזור ההיערכות" – שבו אתה לְהוֹסִיף שינויים שאתה רוצה להיות מחויב.

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

|– נהגים/
| |– spi.c
| |– spi.h
| |– display.c
| |– display.h
|– אפליקציה/
| |– app.c
|– …

בנית בשמחה את מנהל ההתקן SPI שלך, אבל בדרך, יש לך רעיון לעיבוד דפים בצורה חלקה יותר בתצוגה שלך. אתה מכניס כמה שינויים לדרייבר התצוגה שלך, ועכשיו יש לך שינויים גם ב-spi.c וגם ב-display.c. אם אתה מבצע את הכל בבת אחת ("git add .") אז אתה מסתבך שינויים שאינם קשורים, וזה לא היגיינת גיט טובה. מה אם הצגת באג תוך כדי ניסיון להתחכם עם מנהל ההתקן של התצוגה שלך? תצטרך להחזיר את התיקון הזה ואז לבחור את החלקים שקשורים רק ל-SPI כדי להציל אותם מהפלה. מסוקס!

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

git add Drivers/spi.c
git commit…
git add Drivers/display.c
git commit…

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

כאשר השינויים האטומיים מותאמים לקבצים בודדים, קל להקניט שינויים עצמאיים ל-commits שונים. אבל מה אם יש שינויים ב-app.c שחלים על שניהם שינויים ב-SPI ותצוגה? שוב, Git מכסה את זה.

  1. הוספת שינויים בודדים עם -patch

ללמוד על אזור הבמה זה דבר אחד, אבל להבין שאתה יכול לסנן דרך שינויים מ בתוך קובץ בודד פותח עולם חדש של יכולות. לפקודת "git add" יש אפשרות "–patch/-p" שלוקחת אותך חתיכה אחר חתיכה דרך הקבצים שהעברת אליה, ומאפשרת לך למשוך רק את מה שאתה צריך עבור ה-commit. אתה יכול להיות מאוד ספציפי עם תוספות, פיצול חתיכות מסופקות ואפילו בחירת שורות ידנית על ידי עריכתן. בונוס של בניית התחייבויות חתיכה אחר חתיכה הוא שכנראה תכתוב הודעת התחייבות טובה יותר, כי השינויים יהיו רעננים בראש שלך.

טיפ: השתמש ב- אפשרות תצורת "singleKey". כדי להפוך את הניווט למהיר יותר (git config –global interactive.singleKey true). תזדקק למודול Term::ReadKey כדי שזה יעבוד.

האפשרות "–patch" זמינה ביותר פקודות מאשר רק "הוסף". רוצה לזרוק הערה אגרסיבית פסיבית במיוחד מקובץ? "git reset –patch"! או רוצה לשמור רק שורה או שתיים במחסן שלך למועד מאוחר יותר? "git stash –patch"!

  1. Git History

"ההיסטוריה תהיה טובה אליי, כי אני מתכוון לכתוב אותה."

  • אתה, פותח את יחסי הציבור הבא שלך

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

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

אולי ענף התכונות נראה קצת כך:

$ git log –oneline –graph feature_branch
* (feature_branch) תוקנה בעיית מקרה גבול.
* דרייבר לתצוגה של Refactor.
* שיפורים בעיבוד דף.
* התצוגה מעבדת עמוד אחר עמוד.
* (עיקרי) …

כאשר אתה ממזג את הסניף הזה, הוא ישא איתו את כל ההיסטוריה הזו. זה היסטוריה זה לאף אחד לא אכפת. בעוד 5 שנים כשאתה סוקר את ההיסטוריה של הפרויקט, לאף אחד לא יהיה אכפת מבאגים שהוצגו ב-commit אחד ותוקנו כבר ב-commit הבא. אכפת לך מההתחייבויות האלה כמחסומים במהלך הפיתוח, אבל ברגע שהכל יעבוד, לא תצטרך לזכור איך הגעת לשם. הסוקרים רק רוצים לראות את ערכת השינויים המינימלית שמעבירה את הפרויקט מקדם תכונה לפוסט תכונה, אולי עם כמה אבני דרך חשובות ביניהם. אז איך מתמודדים עם זה? אתה יכול לחכות להתחייב על כל דבר עד שהתכונה תיכתב ותעבוד ב-100%, אבל זו נקודה מסוכנת להיות באמצע הפיתוח.

Git נחלץ שוב להצלה עם "git rebase -interactive", המאפשר למשתמשים לערוך באופן אינטראקטיבי היסטוריית commit. אתה יכול לסדר מחדש, לערוך, להוריד או "למעוך" מחויבות מההיסטוריה. שים לב שבסיס מחדש אינטראקטיבי משנה את היסטוריית ה-Git שלך. זה הופך אותם למסוכנים מאוד. אתה יכול לפגוע קשות במאגר שלך כאן אם לא תיזהר.

אני ממליץ להגדיר את המארח המרוחק של git כך שיאפשר רק הרשאות "הריצה לאחור" למפתחים בסניפים התואמים תבנית כמו "dev/*". זה ישמור על הסניף הראשי ונקודות ביקורת חשובות אחרות ללא קשר למה שהמפתחים שלך יעשו. בפרויקטים שלי, "היפוך לאחור" מותר רק בענפים התואמים "tmp/*" ו-"dev/*". ברגע שהשינויים יהיו בענף תכונות משותף או "ראשי", ההיסטוריה לא תשתנה יותר! במידת האפשר, קח את הרעיון הזה למסקנה ההגיונית שלו על ידי איסור כל דחיפה לסניף "הראשי", אלא אם כן הם מגיעים מבקשת משיכה מקובלת.

אם נבקר מחדש בסניף התכונה לדוגמה שלנו, הנה איך נראית ההיסטוריה לאחר ניקוי:

$ git rebase –interactive main..feature_branch
$ git log –oneline –graph feature_branch
* (feature_branch) מנהל התקן תצוגת Refactor.
* התצוגה מעבדת עמוד אחר עמוד.
* (עיקרי) …

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

שמירה על היסטוריה אמינה היא אחת הסיבות להשתמש ב-VCS – ניהול תצורה הוא דרישת מפתח של IEC 62304 עבור תוכנת מכשור רפואי. השתמש בבסיס מחדש אינטראקטיבי כדי להפוך את ההיסטוריה שלך לברורה ולראות איך התוכנה התקדמה בין שתי מהדורות.

סיכום

שמירה על היסטוריה ברורה היא היבט קריטי בפיתוח תוכנה של מכשור רפואי. בעת פיתוח פונקציונליות מרגשת ורחבת טווח עבור מוצרי מכשור רפואי, אזור ההיערכות העוצמתי של Git ותכונות ה-rebasing האינטראקטיביות ישאירו אותך לזוז מהר ולהישבר פחות.

תמונה: Adobe Stock

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





קישור לכתבת המקור – 2024-01-16 01:36:19

Facebook
Twitter
LinkedIn
Telegram
WhatsApp
Email
פרסומת
X-ray_Promo1

עוד מתחומי האתר