🥇איך ליישם מנתח קוד סטטי בפרויקט מדור קודם ולא להפחית את המוטיבציה של הצוות

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

מבוא

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

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

נושאים

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

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

תוצאות חיוביות כוזבות אינן בעיה אם הנתח הסטטי כבר מוגדר:

השבתה קבוצות כללים לא רלוונטיות;
כמה אבחונים לא רלוונטיים הושבתו;
אם אנחנו מדברים על C או C++, אז מסומנים פקודות מאקרו המכילות מבנים ספציפיים שגורמים להופעת אזהרות חסרות תועלת בכל מקום שבו נעשה שימוש בפקודות מאקרו כאלה;
פונקציות משלו מסומנות המבצעות פעולות דומות לפונקציות מערכת (אנלוגי משלה memcpy או הדפס) [4];
תוצאות חיוביות כוזבות מושבתות במיוחד באמצעות הערות;
וכן הלאה.

במקרה זה, אנו יכולים לצפות לשיעור חיובי שווא נמוך של כ-10-15% [5]. במילים אחרות, 9 מתוך 10 אזהרות מנתח יצביעו על בעיה אמיתית בקוד, או לפחות "קוד בעל ריח חזק". מסכים, התרחיש הזה נעים ביותר, והנתח הוא חבר אמיתי של המתכנת.

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

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

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

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

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

זו אותה אנלוגיה כמו אזהרות מהדר. לא בכדי הם ממליצים להשאיר את מספר אזהרות המהדר על 0. אם יש 1000 אזהרות אז כשיהיו 1001 אף אחד לא ישים לב לזה ולא ברור איפה לחפש את האזהרה החדשה ביותר הזו.

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

יישום וביטול חובות טכניים

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

CI / CD

יתר על כן, ניתן להפוך את המנתח באופן מיידי לחלק מתהליך הפיתוח המתמשך. לדוגמה, הפצת PVS-Studio מכילה כלי עזר לצפייה נוחה בדוח בפורמט הדרוש לך, והודעות למפתחים שכתבו קטעים בעייתיים בקוד. למי שמעוניין יותר להשיק את PVS-Studio ממערכות CI/CD, אני ממליץ להכיר את התואם סָעִיף תיעוד וסדרת מאמרים:

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

תיקון חוב טכני קיים והתמודדות עם אזהרות חדשות

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

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

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

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

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

תיקוני באגים ושחזורים

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

if (a = b)

רוב המהדרים והנתחים של C++ מתלוננים על קוד כזה, מכיוון שיש סבירות גבוהה שהם באמת רצו לכתוב (א == ב). אבל יש הסכמה שלא נאמרה, ובדרך כלל זה מצוין בתיעוד, שאם יש סוגריים נוספים, אז נחשב שהמתכנת כתב קוד כזה בכוונה, ואין צורך לקלל. לדוגמה, בתיעוד PVS-Studio לאבחון V559 (CWE-481) כתוב בבירור שהשורה הבאה תיחשב נכונה ובטוחה:

if ((a = b))

דוגמה אחרת. האם זה נשכח בקוד C++ הזה? לשבור או לא?

case A:
  foo();
case B:
  bar();
  break;

מנתח ה-PVS-Studio יוציא כאן אזהרה V796 (CWE-484). ייתכן שזו לא שגיאה, ובמקרה זה עליך לתת למנתח רמז על ידי הוספת התכונה [[ליפול דרך]] או למשל __תכונה__((נפילה)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

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

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

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

כמו כן, אנו תמיד עוזרים ללקוחותינו להקים את PVS-Studio אם מתעוררים קשיים כלשהם. יתרה מכך, היו מקרים שבהם אנחנו בעצמנו ביטלנו אזהרות שווא ותיקנו שגיאות [8]. ליתר ביטחון, החלטתי לציין שגם אפשרות זו לשיתוף פעולה מורחב אפשרית :).

שיטת ראצ'ט

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

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

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

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

למחבר המאמר יש גם דו"ח בנושא זה: "ניתוח סטטי מתמשך".

מסקנה

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

יש עוד ספקות אופייניים לגבי האם ניתוח סטטי באמת יכול להיות נוח ושימושי. ניסיתי להפיג את רוב הספקות הללו בפרסום "סיבות להכנסת מנתח הקוד הסטטי PVS-Studio לתהליך הפיתוח" [9].

תודה על תשומת הלב ובואו להוריד ונסה את מנתח PVS-Studio.

קישורים נוספים

אנדריי קרפוב. כיצד אוכל לראות במהירות אזהרות מעניינות שהנתח PVS-Studio מפיק עבור קוד C ו-C++?
ויקיפדיה. משפט רייס.
אנדריי קרפוב, ויקטוריה חאנייבה. שימוש בלמידת מכונה בניתוח סטטי של קוד המקור של התוכנית.
PVS-סטודיו. תיעוד. הגדרות אבחון נוספות.
אנדריי קרפוב. מאפיינים של מנתח PVS-Studio באמצעות הדוגמה של ספריות ליבה של EFL, 10-15% חיוביות שגויות.
PVS-סטודיו. תיעוד. דיכוי המוני של הודעות מנתח.
איבן אנדריישין. על האופן שבו בדקנו ניתוח סטטי בפרויקט שלנו של סימולטור חינוכי של ניתוחי רנטגן אנדווסקולריים.
פאבל ארמייב, סוויאטוסלב רזמיסלוב. כיצד צוות PVS-Studio שיפר את קוד Unreal Engine.
אנדריי קרפוב. סיבות להכניס את מנתח הקוד הסטטי PVS-Studio לתהליך הפיתוח.

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

מקור: www.habr.com

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