תפקיד איכות הקוד: מדדים קריטיים והשפעתם

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

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

מהי איכות קוד?

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

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

למה איכות הקוד חשובה

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

מדדי איכות קוד: מקור מלא

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

מדדי מורכבות

מורכבות סיקלומטית מודד את מספר הנתיבים הבלתי תלויים ליניארית דרך פונקציה או שיטה. הוא הוצג על ידי תומאס מקייב בשנת 1976 ונשאר מדד הסיבוכיות הנפוץ ביותר. הנוסחה סופרת נקודות החלטה, if, else if, switch מקרים, תנאי לולאה, catch בלוקים, ואופרטורים מותנים, ומחבר 1. פונקציה ללא ענפים היא בעלת סיבוכיות ציקלומטית של 1.

מורכבות סיקלומטית	פרשנות
1-5	פשוט, קל לבדיקה
6-10	בינוני, ניתן לניהול
11-20	מורכב, בדיקות הופכות לקשה
21-50	סיכון גבוה מאוד, מומלץ לבצע שינויים מחדש
50 +	לא ניתן לבדיקה, כמעט ודאי שיש פגמים

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

מורכבות NPath סופר את מספר נתיבי הביצוע הייחודיים דרך פונקציה, כולל נתיבים שנוצרו על ידי תנאים ולולאות מקוננות. כאשר מורכבות ציקלומטית סופרת ענפים באופן ליניארי, מורכבות NPath מכפילה אותם: פונקציה עם שלושה בלוקים עוקבים מסוג if-else היא בעלת מורכבות ציקלומטית של 4 אך מורכבות NPath של 8, מכיוון שכל תנאי יכול להיות true או false באופן עצמאי. מורכבות NPath גדלה באופן אקספוננציאלי עם הקינון. ערך מעל 200 מציין פונקציה שתדרוש יותר מקרי בדיקה ממה שכל צוות יכול לכתוב באופן מציאותי.

מורכבות קוגניטיבית הוצג על ידי SonarSource ומודד כמה קשה להבין קוד ולא כמה נתיבים הוא מכיל. הוא מעניש קינון בצורה חמורה יותר מאשר הסתעפות ליניארית: if בתוך א while בתוך אחר if ציונים גבוהים יותר משלושה ציונים רצופים if משפטים בעלי אותה מורכבות ציקלומתית. מורכבות קוגניטיבית מתיישבת טוב יותר עם הקושי בפועל שחווים מפתחים בעת קריאת קוד. מורכבות קוגניטיבית מעל 15 לכל מתודה מסומנת בדרך כלל לבדיקה; מעל 25 היא מצביעה על פונקציה שרוב המפתחים יתקשו באמת להסיק לגביה.

מדדי הלסטד להפיק משפחה של מדדים מארבע ספירות בקוד המקור: אופרטורים נפרדים (n1), אופרטורים נפרדים (n2), סך אופרטורים (N1) וסך אופרטורים (N2). מאלה, הלסטד מחשב:

• תכולה (N × log2(n)): גודל המימוש בתוכן המידע
• קושי (n1/2 × N2/n2): הערכה של כמה קשה לכתוב או להבין את הקוד
• מַאֲמָץ (נפח × קושי): המאמץ המנטלי הכולל המשוער ליישום או להבין את הקוד

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

מדדי תחזוקה

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

הנוסחה של Visual Studio מייצרת ציון מ-0 עד 100:

מדד תחזוקה	דֵרוּג
20-100	ניתן לתחזוקה (ירוק)
10-19	דאגה בינונית לתחזוקה (צהוב)
0-9	קשה לתחזוקה (אדום)

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

שורות קוד (LOC) ו-KLOC מדוד את גודל בסיס הקוד בשורות או באלפי שורות. פונקציה ציקלומטית (LOC) לבדה לא אומרת דבר על איכות, אך היא מספקת מכנים חיוניים למדדים אחרים: צפיפות פגמים היא באגים לכל KLOC, צפיפות הערות היא הערות לכל LOC, צפיפות בדיקות היא הצהרות בדיקה לכל LOC. פונקציה ציקלומטית גם מודדת את עלות המורכבות: פונקציה של 500 שורות עם מורכבות ציקלומטית של 20 היא בעיה גדולה בהרבה מפונקציה של 50 שורות עם אותו ציון.

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

מדדי כיסוי קוד

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

מדדי תעשייה לכיסוי בדיקות יחידה:

• מתחת ל-50%: לא מספק, רוב הפגמים לא יתגלו בבדיקות
• 50-75%: בינוני, נתיבים עיקריים מכוסים, מקרי קצה כנראה הוחמצו
• 75-90%: טוב עבור רוב קוד היישומים
• מעל 90%: מתאים למערכות קריטיות לבטיחות או בעלות אמינות גבוהה

כיסוי קוד ביישומים קריטיים לבטיחות עומד בתקנים מחמירים יותר. DO-178C עבור תוכנות תעופה ו-IEC 61508 עבור בטיחות פונקציונלית מפרטים דרישות כיסוי (כיסוי MC/DC עבור רמות הקריטיות הגבוהות ביותר) החורגות ממה שמשיגות בדיקות יחידה סטנדרטיות. שיפור איכות הקוד ביישומים קריטיים לבטיחות דורש כלי כיסוי שעוקבים אחר כיסוי מצבים/החלטות ויכולים לייצר את הראיות הפורמליות הנדרשות על ידי רשויות ההסמכה.

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

מדדי פגמים

צפיפות באג צפיפות הפגמים (או צפיפות פגמים) היא מספר הפגמים שאושרו לכל אלף שורות קוד (KLOC). זהו המדד הכמותי הישיר ביותר לתקינות הקוד. מדדי תעשייה מ-CISQ מצביעים על כך שתוכנה מסחרית מוכנה יש בממוצע כ-15-50 פגמים לכל KLOC לפני הבדיקה; לאחר הבדיקה והשחרור, תוכנה מסחרית באיכות גבוהה בדרך כלל פועלת מתחת לפגם אחד לכל KLOC.

ממצאי ניתוח סטטי צפיפות פגמים משוערת לפני אישור הפגמים באמצעות בדיקות או שימוש בייצור. כלים כמו SonarQube, Checkmarx ו- SMART TS XL ניתוח בסיס הקוד לאיתור דפוסים הקשורים לפגמים ידועים ופגיעויות, תוך יצירת ספירה של בעיות פוטנציאליות המסווגות לפי חומרה. היחס בין ממצאים קריטיים וחוסמים לבין LOC מספק איתות מוקדם לאיכות הקוד לפני שהקוד מגיע לבדיקה.

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

מדדי קריאות וסגנון

צפיפות הערות הוא היחס בין שורות ההערות לשורות הקוד. טווחים אופטימליים משתנים בהתאם לשפה ולמוסכמות הצוות אך בדרך כלל נעים בין 10-30%. מתחת ל-10% עשויים להצביע על קוד שאינו מתועד כראוי; מעל 50% עשויים להצביע על קוד כה מורכב עד שהוא דורש הסבר נרחב של לוגיקה שאינה ברורה מאליה. איכות ההערות חשובה יותר מהכמות: הערה שחוזרת על מה שהקוד עושה (// increment i by 1) לא מוסיף דבר, בעוד שהערה המסבירה מדוע נבחר אלגוריתם ספציפי מוסיפה ערך משמעותי.

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

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

מדדי אבטחה וחוב טכני

יחס חוב טכני מוגדר על ידי SonarQube כיחס בין עלות התיקון המשוערת לעלות הפיתוח המשוערת של בסיס הקוד. יחס חוב טכני מתחת ל-5% נחשב לבסיס קוד נקי; מעל 20% מצביע על חוב מצטבר משמעותי שיאט באופן משמעותי את הפיתוח העתידי.

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

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

כיצד למדוד איכות קוד: גישה מעשית

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

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

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

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

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

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

מדדי איכות קוד בפיתוח אג'ילי

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

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

איכות קוד לבדיקת נאותות טכנית

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

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

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

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

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

• מגבלות הסיבוכיות הציקלומטיות נקבעות בדרך כלל על 10 או פחות, וחריגים דורשים הצדקה רשמית.
• דרישות הכיסוי משתמשות בכיסוי MC/DC (Modified Condition/Decision Coverage) ולא בכיסוי קו או סניף.
• יש לבצע ניתוח סטטי באמצעות כלים מוסמכים ויש לתעד את ההפרות ולפתור אותן או לקבל אותן רשמית.
• נטישת קוד מנוטרת כאינדיקטור בטיחות: שיעורי שינוי גבוהים במודולים קריטיים לבטיחות מפעילים סקירה נוספת ותיקוף מחדש.

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

מדדי איכות קוד לפי שפה

מדדי איכות קוד פייתון ניתן לחשב באמצעות radon (מדד מורכבות ותחזוקה ציקלומטי), pylint (ריחות קוד והפרות סגנון), coverage.py (כיסוי מבחן), bandit (בעיות אבטחה), ו mypy or pyright (תקינות סוג). מדד התחזוקה ב radon משתמש בנוסחת הלסטד שעברה התאמה ל-Python. ציון A הוא מעל 20, ציון B הוא 10-20, ציון C הוא מתחת ל-10.

איכות קוד RPG ב-IBM i דורש כלים ייעודיים מכיוון שכלי מטריקה באיכות סטנדרטית אינם מנתחים תחביר RPG. SMART TS XL מספק ניתוח מורכבות ציקלומאטית, שורות קוד וניתוח תלות עבור תוכניות RPG, דבר בעל ערך רב במיוחד עבור חנויות IBM i המנהלות בסיסי קוד גדולים מדור קודם, שבהם מדידת איכות הייתה בעבר בלתי אפשרית לאוטומציה.

מדדי סקירת קוד

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

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

צוותים בעלי ביצועים גבוהים בדרך כלל מציגים כיסוי סקירה מעל 90%, ממוצע פגמים שנמצאו לסקירה בין 1-3 לכל מאה שורות שנבדקו, וזמני אספקה ​​קצרים. מדדי סקירה עוזרים לזהות האם סקירת קוד מתפקדת כשער איכות או כפורמליות.

ניטור איכות קוד רציף

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

ניטור יעיל ורציף של איכות הקוד כולל:

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

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

איך SMART TS XL מודד ומשפר את איכות הקוד

SMART TS XL מחשב את מערך מדדי איכות הקוד המלא המתוארים במאמר זה בכל שפה ופלטפורמה בסביבת הפיתוח: COBOL, JCL, Java, .NET, Python, JavaScript, TypeScript, RPG, SQL ואחרים. כאשר רוב כלי האיכות פועלים על שפה אחת בכל פעם, SMART TS XL בונה מודל איכות מאוחד של המערכת כולה, המאפשר להשוות איכות בין שפות שונות, לעקוב אחר מדדים ברמת המערכת ולא ברמת הקובץ, ולזהות בעיות איכות חוצות רכיבים שכלים בשפה אחת אינם יכולים לראות.

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

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

איכות קוד היא תחום צוותי, לא דוח

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

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