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

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

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

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

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

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

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

3. שימוש ב Git Hooks כדי לוודא הודעות קומיט מפורטות בגיט.

4. הכנסת שידרוגי תלויות ותשתית בתור משימה חוזרת ב Jira, פעם ב X ספרינטים.

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