בניית תוכנה יכולה להרגיש כמו הופעה בפני קהל. האינטרנט מתגמל השקות, צילומי מסך ונקודות בשינויי הגרסה (changelog). לכן, כשמפתח מקדיש סשן שלם לפרויקט ולא יוצא לו שום דבר נראה לעין, האינסטינקט הוא להחשיב את היום הזה כבזבוז זמן. יומן הפיתוח (dev log) האחרון של פלטפורמת בלוג האוכל מוכיח את ההפך. לא היו מתכונים חדשים להצגה, לא היו כרטיסים מעוצבים מחדש, ולא היו כפתורים נוספים למשתמשים ללחוץ עליהם. רק קוד שפורק, נבחן וחובר מחדש בצורה טובה יותר מבעבר.
זהו העבודה הבלתי נראית ששומרת על פרויקטים ארוכי טווח בחיים.
פיצ'רים מקבלים את התהילה; ריפקטורינג שומר על האורות דולקים
כשאתה מנהל פלטפורמת בלוג אוכל, המעטפת נראית פשוטה. משתמשים מפרסמים מתכונים, מעלים תמונות וגולשים לפי קטגוריות. מתחת לפני השטח, עם זאת, אתה מתמרן בין צינורות עיבוד תמונה (image pipelines), קשרי מסד נתונים בין מרכיבים להוראות, אינדקסים לחיפוש ושכבות מטמון (caching layers). עם הזמן, תיקונים מהירים מצטברים. פונקציית עזר שהועתקה לשלושה קבצים שונים. שאילתת מסד נתונים שהייתה הגיונית עבור עשרה פוסטים, אך הופכת לאיטית מאוד כשמגיעים לאלף. CSS שהתחיל מאורגן עד שחמישה תיקוני חירום הפכו אותו למבוך.
ריפקטורינג (Refactoring) פירושו להתמודד עם הבלגן הזה פנים אל פנים. זה עשוי להשתמע כאיחוד לוגיקה כפולה, כך שתיבת עריכת מתכון ולוח בקרה של מנהל (admin dashboard) יישבו על אותה שכבת וולידציה (validation layer) במקום לתחזק גרסאות מקבילות. זה עשוי להשתמע כפישוט אופן עיבוד התמונות, כך ששגרת הדחיסה תרוץ פעם אחת במקום בכל פעם שהדף נטען מחדש. או שזה עשוי לכלול ארגון מחדש של בסיס הקוד (codebase), כך שהוספת סוג תוכן חדש בהמשך לא תדרוש חיפוש בשישה ספריות לא קשורות.
שום דבר מזה לא מופיע בממשק המשתמש. מבקר שנכנס לאתר לא יראה באנר שאומר "שאילתה מותאמת" (query optimized) או "רכיב מנותק" (component decoupled). אבל הוא ירגיש את זה כשהאתר ייטען מהר יותר. הוא יבחין בכך שפיצ'ר חדש מופיע שלושה ימים אחרי שנתבקש במקום שלושה שבועות. המפתח לא הוסיף יכולות היום. הוא פתח את הדרך כדי שניתן יהיה להוסיף יכולות מבלי להילחם בבסיס הקוד.
קוד נקי הוא השקעה נגד כישלון עתידי
כל פרויקט שנמשך יותר מחודש צובר חיכוך. בונים אב-טיפוס מהיר כדי לבדוק רעיון. ואז משתמשים באמת מגיעים. ואז צריך שכבת אימות (authentication layer), ואז תור ניטור (moderation queue), ואז פריסת מובייל. כל אחת מהתוספות הללו מחוברת למבנה הקיים. ללא תחזוקה שוטפת, הארכיטקטורה מתחילה להזכיר בית שבו כל חדר חדש תוכנן על ידי אדם אחר שמעולם לא ראה את תוכנית הבית.
חוב טכני (Technical debt) אינו כישלון של משמעת. הוא תוצר לוואי טבעי של עשיית פשרות (trade-offs) כדי להוציא מוצר אמיתי לשוק. הסכנה היא לא שהקוד שלך אינו מושלם. הסכנה היא להשאיר אותו לא מושלם זמן רב כל כך, עד ששינוי משתנה אחד שובר שלושה פיצ'רים לא קשורים. אתה מוצא את עצמך מפחד לגעת בשורת החיפוש כי בפעם האחרונה שניסית, מערכת התגיות נשברה. אתה דוחה הוספה של ווידג'ט מתכנן ארוחות כי אתה יודע שסכימת מסד הנתונים הפכה לקשר שייקח שעות להתיר.
להקדיש יום לריפקטורינג זה כמו לשלם את החוב הזה לפני שהריבית תציף אותך. זה מונע מהבעיות הקטנות להתגבש לבעיות גדולות. כשהפלטפורמה של בלוג האוכל תוסיף בסופו של דבר את הפיצ'ר המשמעותי הבא שלה, המפתח לא יצטרך לרקוד סביב קוד שביר. הוא יכתוב את הלוגיקה החדשה, יחבר אותה לממשק נקי, וימשיך הלאה. זהו ההחזר על ההשקעה.
צעדים קטנים, למידה אמיתית
קיימת מיתולוגיה סביב פיתוח תוכנה שאומרת שההתקדמות נראית כמו פריצות דרך גאוניות וסשנים של כתיבת קוד במרתון שכותבים הכל מחדש בן לילה. רוב המפתחים המקצועיים יגידו לך שזה פנטזיה. התקדמות אמיתית נראית כמו ה-diff משישי אחר צהריים שבו שלוש פונקציות התקצרו, תלות מיותרת (redundant dependency) אחת הוסרה, ושם משתנה מבלבל שונה כדי שהקורא הבא באמת יבין מה הוא עושה.
יומן הפיתוח של פלטפורמת בלוג האוכל לוכד את הקצב הזה בצורה מושלמת. בניית תוכנה עוסקת בשיפורים קטנים ועקביים. לומדים מכל אתגר. אולי היום האתגר היה להבין מדוע מודול מסוים הפך לתלוי כל כך במודול אחר. אולי זה היה ההבנה שקיצור דרך שנלקח לפני שבועיים כבר התחיל לעלות יותר זמן ממה שחסך. כל commit הופך את הפרויקט לטוב יותר, גם כש-commit הזה מוחק יותר ממה שהוא יוצר.
הגישה הזו גם שומרת על המוטיבציה שלך. כתיבות מחדש מסיביות הן מתישות ומסוכנות. הן מביאות איתן באגים חדשים תוך כדי פתרון ישנים. רפקטורינג הדרגתי, מבוצע