🥇ניתוח סטטי – ממבוא לאינטגרציה

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

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

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

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

למה אתה צריך ניתוח סטטי?

בקצרה: האצה ופישוט.

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

auto x = obj.x;
auto y = obj.y;
auto z = obj.z;

כתבת את הקוד הבא:

auto x = obj.x;
auto y = obj.y;
auto z = obj.x;

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

V537 שקול לבדוק את נכונות השימוש בפריט 'y'.

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

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

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

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

אתה יכול למצוא שגיאות מעניינות יותר שהנתח יכול לזהות במאמרים:

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

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

0. היכרות עם הכלי

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

מה תלמדו בשלב זה:

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

לאחר שהתקנת את כל מה שאתה צריך, הדבר הראשון שאתה צריך לעשות הוא להפעיל ניתוח של כל הפרויקט (Windows, Linux, macOS). במקרה של PVS-Studio ב-Visual Studio תראה תמונה דומה (ניתן ללחוץ):

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

ואכן, 178 אזהרות הרבה יותר קלות לצפייה מאשר כמה אלפי...

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

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

1. אוטומציה

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

מה תלמדו בשלב זה:

אילו אפשרויות אוטומציה מספק הכלי;
האם המנתח תואם למערכת ההרכבה שלך?

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

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

PVS-Studio_Cmd.exe (ניתוח פתרונות, פרויקטים של C#, C++ בנושא Windows)
CLMonitor.exe (מעקב אחר קומפילציה)
pvs-studio-analyzer (ניתוח של פרויקטים של C++ ב Linux / macOS)
pvs-studio-dotnet (ניתוח פתרונות, פרויקטים ב-C# Linux / macOS)
pvs-studio.jar (ניתוח של פרויקטי Java)
PlogConverter (ממיר קבצי דוחות)

כדי לשלב ניתוח ב-CI, עליך לעשות שלושה דברים:

התקן את הנתח;
הפעל ניתוח;
לספק תוצאות.

לדוגמה, כדי להתקין את PVS-Studio על Linux (Debian-base) עליך להריץ את הפקודות הבאות:

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list
  
sudo apt-get update -qq
sudo apt-get install -qq pvs-studio

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

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

למידע נוסף על פריסת PVS-Studio במערכות הפועלות Windows אתה יכול לקרוא *כאן*.

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

מכיוון ששיטת ההפעלה תלויה בפלטפורמה ובתכונות הפרויקט, אציג את האפשרות עבור C++ (Linux) כדוגמה:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log
plog-converter -t errorfile PVS-Studio.log --cerr -w

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

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

תוכל לקרוא עוד על הגדרת ניתוח על CI במאמר "PVS-Studio ושילוב רציף"(Windows) או "כיצד להגדיר את PVS-Studio ב-Travis CI"(Linux).

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

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

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

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

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

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

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

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

2. אינטגרציה על מכונות מפתחים

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

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

לאחר מכן תצטרך להתקין את התוספים הדרושים, למשל עבור של Visual Studio, IDEA, רוכב וכו '

3. שימוש יומיומי

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

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

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

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

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

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

לאחר אינטגרציה

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

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

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