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

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

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

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

ראצ'ט (מקור: ויקיפדיה).

מה שמנתחים סטטיים לעולם לא יכולים לעשות

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

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

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

ניתוח סטטי אינו עוסק במציאת באגים

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

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

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

ניתוח סטטי הוא יותר מאשר מציאת באגים

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

• בדיקת סגנון קידוד במובן הרחב של המילה. זה כולל גם בדיקת עיצוב, חיפוש אחר שימוש בסוגריים ריקים/נוספים, קביעת סף על מדדים כמו מספר שורות/מורכבות ציקלומטית של שיטה וכו' - כל דבר שעלול להפריע לקריאה ולתחזוקה של הקוד. ב-Java, כלי כזה הוא Checkstyle, ב-Python - flake8. תוכניות של מחלקה זו נקראות בדרך כלל "לינטרים".
• לא רק קוד הפעלה ניתן לניתוח. ניתן (וצריך!) לבדוק אוטומטית קובצי משאבים כגון JSON, YAML, XML, .properties. אחרי הכל, עדיף לגלות שמבנה ה-JSON שבור בגלל כמה ציטוטים לא מתאימים בשלב מוקדם של אימות Pull Request אוטומטי מאשר במהלך ביצוע הבדיקה או זמן הריצה? כלים מתאימים זמינים: למשל. YAMLlint, JSONLint.
• קומפילציה (או ניתוח לשפות תכנות דינמיות) הוא גם סוג של ניתוח סטטי. באופן כללי, מהדרים מסוגלים להפיק אזהרות המעידות על בעיות באיכות קוד המקור ואין להתעלם מהן.
• לפעמים קומפילציה היא יותר מסתם קומפילציה של קוד הפעלה. לדוגמה, אם יש לך תיעוד בפורמט AsciiDoctor, ואז ברגע הפיכתו ל-HTML/PDF המטפל AsciiDoctor (תוסף Maven) יכול להוציא אזהרות, למשל, על קישורים פנימיים שבורים. וזו סיבה טובה לא לקבל את ה-Pull Request עם שינויים בתיעוד.
• בדיקת איות היא גם סוג של ניתוח סטטי. תוֹעֶלֶת לשאוף מסוגל לבדוק איות לא רק בתיעוד, אלא גם בקודי מקור של תוכנות (הערות ומילוליות) בשפות תכנות שונות, כולל C/C++, Java ו-Python. גם שגיאת כתיב בממשק המשתמש או בתיעוד היא פגם!
• מבחני תצורה (על מה הם - ראה. זה и זה דוחות), למרות שהם מבוצעים בזמן ריצה של בדיקת יחידה כגון pytest, הם למעשה גם סוג של ניתוח סטטי, מכיוון שהם אינם מבצעים קודי מקור במהלך ביצועם.

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

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

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

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

1. ניתוח סטטי
2. הידור
3. בדיקות יחידה
4. מבחני אינטגרציה
5. מבחני ממשק משתמש
6. בדיקה ידנית

שינויים שנדחו בשלב ה-N של הצינור אינם מועברים לשלב N+1.

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

פירמידת בדיקה. מָקוֹר: מאמר מרטין פאולר.

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

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

מסנן רב שלבי. מָקוֹר: ויקישיתוף

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

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

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

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

יישום בפרויקט מדור קודם

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

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

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

השיטות הבאות להחדרת שערים איכותיים ידועות:

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

מַחגֵר

זה עובד כך:

1. בשלב הראשוני, מתבצע רישום במטא נתונים על שחרור מספר האזהרות בקוד שנמצא על ידי הנתחים. לכן, כשאתה בונה במעלה הזרם, מנהל המאגר שלך כותב לא רק "גרסה 7.0.2", אלא "גרסה 7.0.2 המכילה 100500 אזהרות בסגנון צ'ק". אם אתה משתמש במנהל מאגר מתקדם (כגון Artifactory), אחסון מטא נתונים כאלה לגבי הגרסה שלך היא קלה.
2. כעת כל בקשת משיכה, כאשר היא בנויה, משווה את מספר האזהרות המתקבלות עם מספר האזהרות הזמינות במהדורה הנוכחית. אם יחסי ציבור מובילים לעלייה במספר זה, אז הקוד לא עובר את שער האיכות לניתוח סטטי. אם מספר האזהרות יורד או לא משתנה, אז זה עובר.
3. במהדורה הבאה, מספר האזהרות המחושב מחדש יירשם שוב במטא נתונים של הגרסה.

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

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

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

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

בכל מערכת CI מתקדמת, ניתן ליישם ראצ'ט עבור כל כלי ניתוח סטטי מבלי להסתמך על תוספים וכלים של צד שלישי. כל מנתח מייצר דוח משלו בפורמט טקסט פשוט או XML שקל לנתח. כל מה שנותר הוא לכתוב את ההיגיון הדרוש בסקריפט CI. אתה יכול לראות איך זה מיושם בפרויקטי הקוד הפתוח שלנו המבוססים על Jenkins ו-Artifactory כאן או כאן. שתי הדוגמאות תלויות בספרייה ratchetlib: שיטה countWarnings() סופר תגיות xml בקבצים שנוצרו על ידי Checkstyle ו-Spotbugs בדרך הרגילה, ו compareWarningMaps() מיישם את אותו ראצ'ט, וזורק שגיאה כאשר מספר האזהרות בכל אחת מהקטגוריות גדל.

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

על החשיבות של תיקון גרסת הנתח

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

ממצאים

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

תזכור

1. משלוח רציף
2. א' קודריאבצב: ניתוח תוכניות: איך להבין שאתה מתכנת טוב דווח על שיטות שונות של ניתוח קוד (לא רק סטטי!)

מקור: www.habr.com