כמה מתכנתים צריך כדי לשמור על קוד שנכתב בעבר?

לפני זמן מה התקיימה שיחה ביני לבין חברה טובה שלי בה נשמעו המשפטים הבאים:

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

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

שאלה ראשונה. האם לתמוך "לאכול" את כל משאבי הפיתוח?

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

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

טבעי להניח שעלויות העבודה לתחזוקת הקוד פרופורציונליות לנפח שלו:

או

מאין

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

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

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

а הוא פתרון למשוואה דיפרנציאלית עם ארגומנט מפגר [1]:

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

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

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

שאלות שלא ניתן היה לענות עליהן:

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

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

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

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

מאין

אם , אז

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

מסקנה

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

הפניות

1. Elsgolts L.E., Norkin S.B. מבוא לתורת משוואות דיפרנציאליות עם טיעון סוטה. מוסקבה. הוצאת הספרים "מדע". 1971.
2. ארנולד V.I. מודלים מתמטיים "קשים" ו"רכים". מוסקבה. בית ההוצאה לאור MCNMO. 2004.

מקור: www.habr.com