Refactoring בלי לעצור את העולם

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

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

כי אין רגע שבו העולם עוצר.

האשליה: “ננקה ואז נתקדם”

התסריט האופטימי מוכר:

• נקדיש זמן ל-cleanup
• נפריד שכבות
• נסדר dependencies
• ואז נבנה נכון

בפועל, זה כמעט אף פעם לא קורה.

בזמן ה-Refactor:

• דרישות חדשות ממשיכות להגיע
• תקלות ממשיכות לקרות
• משתמשים לא מחכים
• וצוותים אחרים ממשיכים להסתמך על הקיים

המערכת לא מחכה שתהיה יפה יותר.

למה ריפקטורים גדולים נכשלים

רוב הריפקטורים הגדולים לא נכשלים בגלל קוד גרוע, אלא בגלל הקשר שגוי.

הם מניחים ש:

• אפשר להקפיא התנהגות
• אפשר לשנות הרבה דברים יחד
• ואפשר “להחליף” מערכת אחת באחרת

אבל במערכת רצה:

• כל שינוי מפעיל שרשרת תגובות
• כל נקודת מגע היא סיכון
• וכל עיכוב מייצר לחץ חדש

ככל שהריפקטור גדול יותר - כך גדל הסיכוי שלא יושלם לעולם.

שינוי הדרגתי בתוך מערכת חיה

Refactoring שעובד נראה אחרת:

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

במקום לשאול: “איך נבנה את זה מחדש?”

שואלים: “איזה שינוי קטן ישפר את המצב בלי לשבור את הזרימה?”

זו לא דרך מהירה. אבל זו דרך שמחזיקה.

מתי הבחירה הנכונה היא לא לגעת

יש מקרים שבהם Refactoring הוא הטעות.

לא כי הקוד טוב - אלא כי המחיר גבוה מדי עכשיו.

לדוגמה, כש:

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

השורה התחתונה

במערכת חיה, Refactoring אינו פרויקט.

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

הנדסה בוגרת אינה שואלת: “איך ננקה הכול?”

אלא: “איפה שינוי קטן אחד ישנה את הכיוון?”

מבט קדימה

אם אי אפשר לשפר הכול - צריך לבחור מה לא לשפר.

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