איך אנחנו מחליטים מתי לבצע Refactor ומתי לכתוב מחדש
כל מפתח נתקל ברגע הזה.
בסיס הקוד איטי. הוספת פיצ'רים לוקחת יותר מדי זמן. עובדים חדשים מתקשים להבין את המערכת. בסופו של דבר, מישהו מציע כתיבה מחדש מלאה.
הצוות בדרך כלל מתפצל לשתי קבוצות. קבוצה אחת רוצה להתחיל מחדש. הקבוצה השנייה חוששת מהכישלונות של כתיבות מחדש בעבר. לשני הצדדים יש טיעונים מוצדקים.
כתיבה מחדש אינה פתרון קסם. זה לרוב לוקח יותר זמן ממה שתוכנן. אתם מסיימים בתחזוקה של שתי מערכות במקביל. אתם עלולים אפילו לחזור על אותן טעויות בגרסה החדשה.
כתיבה מחדש הגיונית במקרים הספציפיים הבאים:
• מודל הנתונים שגוי מיסודו עבור העסק. • הטכנולוגיה מיושנת ואין לה עדכוני אבטחה. • הצרכים העסקיים השתנו כל כך, שהמערכת המקורית הפכה למיושנת. • אף אחד בצוות הנוכחי לא מבין איך המערכת עובדת.
גם אז, אל תבצעו החלפה בבת אחת (big bang replacement). השתמשו בתבנית strangler fig. בנו את המערכת החדשה חלק אחר חלק לצד הישנה.
ברוב המקרים, אתם בעצם צריכים לבצע Refactor.
Refactoring הוא הבחירה הנכונה כאשר:
• אתם עדיין יכולים להוסיף פיצ'רים, גם אם זה איטי. • הצוות מבין את הקוד הנוכחי. • הבלגן מוגבל למודולים ספציפיים. • העסק לא יכול להפסיק להוציא פיצ'רים חדשים.
לפני שאתם בוחרים, שאלו למה הקוד הפך לגרוע.
אם הבעיה היא חוב טכני (technical debt), בצעו Refactor לחלקים הגרועים ביותר. אם הבעיה היא חוסר בביקורת קוד (code reviews) או תרבות ארגונית לקויה, כתיבה מחדש לא תעזור. אתם פשוט תבנו בלגן חדש עם אותן הרגלים ישנים.
שאלו את השאלות הבאות לפני שתחליטו:
• האם אנחנו יכולים לתקן את החלקים הגרועים ביותר בבידוד? • האם מודל הנתונים שבור עבור הצרכים העסקיים הנוכחיים? • איזה ידע נאבד אם נתחיל מחדש? • האם לעסק יש את היציבות הנדרשת כדי להתמודד עם תקופת מעבר ארוכה?
להתחיל מחדש זה מרגיש טוב. לסיים את הכתיבה מחדש זה החלק הקשה. ברוב המקרים, תוכנית Refactoring מובנית היא בטוחה ויעילה יותר.
מקור: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk