כאשר 2020 מתקרבת לסיומה (איזו שנה מטורפת, נכון), אנו באינקרדיבילד חוקרים את המגמות הכי רלוונטיות לחברה וללקוחות שלנו.
השנה האחרונה לימדה אותנו שחברות שהשכילו להטמיע אוטומציה בחלקים נרחבים יותר בפעילות שלהן מצליחות לשמור על גמישות ותחרותיות. הדוגמה הטובה ביותר לכך היא מפתחי המשחקים שהיו צפויים להשיק משחקים וגרסאות במהירות רבה יותר מתמיד – והם ניצחו.
כמו הסיפור של how Milestone released MotoGP™20 During Lockdown כיצד Milestone, חברת משחקים איטלקית, ומהראשונות שהחלו לעבוד מהבית, השיקה את MotoGP™20 בזמן הסגר.
תוך שהתכוננתי לקראת 2021, נתקלתי במאמר הזה אשר מתבסס על דוח מאת Sourcegraph ו –Dimensional Research, לפיו 33% מהמפתחים (מתוך יותר מ-500 שנסקרו) מנהלים פי 100 יותר קוד מאשר ניהלו בשנת 2010; מדווח כי 18% מהמפתחים ניהלו פי 500 יותר קוד מאשר ניהלו ב-2010!
Image source: Sourcegraph
מדובר בפי 2-15 יותר שורות קוד בשנה.
נכון, המשמעות אינה שאנו יושבים ובפועל כותבים יותר קוד פי מאות ממה שכתבנו לפני עשור. הרבה השתנה, כמו האימוץ המסיבי של קוד מקור פתוח והעלייה הגדולה בפלטפורמות, התקנים וסביבות ייעודיות.
Image source: Sourcegraph
אבל עבורי, מדובר בנתון שמשנה את חוקי המשחק שכל מי שעוסק בפיתוח תוכנה חייב לשקול תוך שאנו מתכוננים לעתיד.
קוד מתנפח הוא תופעה נרחבת שממשיכה להתרחב. אם המגמה אמיתית, הרי שבתוך שנתיים היא תגדל פי שנים או אפילו שלושה תוך הכבדה על המשאבים והתשתית שלכם.
החוק הראשון של פיתוח תוכנה
החוקר ג’רארד ג’. הולצמן כתב על מגמת ניפוח קוד זו ואמר: “תוכנה נוטה לגדול עם הזמן, בין אם קיים לכך צורך רציונלי או לא. אנו יכולים לכנות זאת כחוק הראשון של פיתוח תוכנה.” אז כן, נראה שהולצמן לקח את מגמת ניפוח הקוד הזו ברצינות רבה אם הרחיק לכנות אותה החוק הראשון של פיתוח תוכנה. הוא המשיך לבחון את התיאוריה הזו. כדי להוכיח את הצמיחה הבלתי הגיונית בקוד, הוא בדק פקודה המכונה true במערכות Unix® ומבוססות Unix. הפקודה צמחה עם הזמן מ-0 ל-22896, עובדה שהוכיחו את הטיעון שלו ואף יותר, תוך שהציגה שאפילו הקוד הטריוויאלי ביותר הופך למנופח. דמיינו כמה התמונה עצובה כשזה מגיע למוצרים מורכבים.
יכול להשפיע על תדירות האיטרציות שלכם
חברות שאינן משתמשות בטכנולוגיות שמאפשרות אדישות לנפח הקוד שלהן תיקברנה תחת אי היעילות בזמני הפיתוח וזמני הקומפילציות שנגזרות כתוצאה מכך ותפגרנה מאחורי כולם. חשבו על זה, מערכות הופכות למערכות מורשת שאי אפשר לתחזק בשל המאמץ שהן דורשות. ומה לגבי יחסי התלות השונים? יחסי התלות נוראיים כשזה מגיע לקוד מנופח או מערכות מורשת. על פי הדוח, 57% מהמשיבים דווחו על שבירת קוד בשל אי הבנת יחסי התלות.
בנסיבות אלה, קמפול מהיר יותר הוא עניין של לעשות או לחדול ואני בספק אם חומרה נוספת תביא בטווח הארוך לפתרון בעיה זו עם זמן קמפול. חייבים איכשהו לקמפל את כל השורות הללו של קוד מנופח… ובתדירות הגבוהה שאנו תמיד מעוניינים להגביר. בנוסף, מהירות היא המהות, אפילו יותר מלפני 10 שנים; הרוב המכריע של המשיבים בדוח זה (92%) אומרים כי הלחץ לשחרור מהיר יותר של הקוד עלה בעשור האחרון. כך שלא רק הקוד המנופח יותר את הצורך בצמצום זמן הקמפול, מדובר גם בדרישה למחזורי איטרציה וקצבי השקה מהירים יותר.
Image source: Sourcegraph
יכול גם לקבוע את איכות המוצר שלכם
יותר קוד משמעו יותר בדיקות, בין אם מדובר בבדיקות קוד (unit tests)), API, אינטגרציה ותפקוד, בדיקות חדירות, ניתוח איכות הקוד או כל שביניהן.
רוב חברות התוכנה היום נמצאות במצב של חוב טכני בכל הנוגע לכיסוי בדיקות ממוחשב. בבחינת המגמה הקדושה למעבר ל-CI/CD אוטומטי לגמרי, כיסוי בדיקות מלא הוא תכונה חיונית אם רוצים להמשיך בשחרור גרסאות תדיר ואיכותי.
קיימות מספר גישות לשמירה אל אינטגרציה שוטפת והתמודדות עם חוב טכני בעידן זה של קוד נפוח. גישה מעניינת מאוד אותה אני בוחן כעת היא מחוללי בדיקות. נתקלתי לאחרונה בכלי מבוסס AI חדש מבית Diffblue אשר מבצע אוטומציה לכתיבת בדיקות עבור Java (הם מציעים גם גרסת Community Edition חינמית למוצר הזה, שיוצרה עם IntelliJ).
ועם כלי AI שמחוללים עשרות אלפי יחידות בדיקה באופן קבוע, ניפוח הבדיקות הוא הבא בתור וזה עלול להגיע להרבה יותר מפי 100.
הכלים הקיימים אינם יכולים להתמודד עם ניפוח קוד (מלבדנו, כמובן)
הדוח מצביע על כך ש-85% מהמשיבים מסכימים כי “הכלים הקיימים אינם מיועדים לעבוד עם בסיס קוד גדולים ובקנה מידה רחב.” זו אחת הסיבות שאני כל גאה לעבודה באינקרדיבילד – אם איננו מצוידים להתמודד עם קוד גדול, הרי שאיננו מאמצים את אחד הטרנדים המוכחים ביותר של השנים האחרונות: Agile Development, ואיננו מוכנים לעתיד שבו כמות הקוד וכמות הבדיקות השונות, כולל בדיקות קוד ואבטחה הולכים לגדול בנפחים משמעותיים כחלק מהמעבר לתהליכי שחרור ובדיקות גרסה אוטומטיים. באמצעות שימוש באינקרדיבילד, חברות התוכנה הגדולות והמובילות בעולם מאפשרות לעצמן להמשיך את הובלתן הטכנולוגית באמצעות שימת דגש על ייעול וזירוז של תהליכי הפיתוח ושחרור מביר של גרסאות לשוק, בין אם באמצעות האצת תהליכי הקומפילציה שלהן ובין אם האצת תהליכים נוספים כחלק מתהליך שחרור גירסה אוטומטית, כגון האצת תהליכי בדיקות אוטומטיות, אריזת המוצר, חתימות דיגיטליות ועוד.
אולי כדאי לעשות קצת ניקיונות
מעבר להתחמשות בטכנולוגיה הנכונה (בשביל זה אנחנו כאן), מומלץ מבחינה טכנולוגית שתבדקו את האפשרות ותיפטרו מקוד מיושן. נכון, הדבר מחייב קצת מאמץ והמון התמדה, והוא לא מתאים לכולם. ישנם מקרים שאינם מתאימים לניקוי קוד או פשוט לא שווים את המאמץ. אבל כשהדבר מתאים – ייתכן שכדאי. אני יודע שהרבה מכם, המפתחים, מנסים להימנע מעדכון קוד כי אתם פוחדים משבירתו (כפי שעולה מתוך הדוח). ובכן, אני יכול רק להגיד – אתם צודקים! אבל כדאי גם לקוד מיותר יש חסרונות משמעותיים שלא כדאי להזניח.
היו מוכנים
חשוב להבין כי ניפוח קוד הוא עניין קיים. הוא כאן, הוא גדל ויכולות להיות לו השלכות חמורות על מחזור הפיתוח, זמן השחרור, תדירות האיטרציות ואיכות המוצר שלכם. עליכם להשקיע בתשתיות, כלים ותהליכים שמטפלים בבעיית הקוד הנפוח כדי שתוכלו להמשיך להוביל בתחומכם.
