Як ми вирішуємо, коли проводити рефакторинг, а коли — переписування

Кожен розробник стикається з цим моментом.

Кодова база працює повільно. Додавання нових функцій займає занадто багато часу. Новим співробітникам важко розібратися в системі. Зрештою, хтось пропонує повне переписування.

Команда зазвичай ділиться на дві групи. Одна хоче почати з чистого аркуша. Інша боїться провалу, як це було під час попередніх спроб переписування. Обидві сторони мають вагомі аргументи.

Переписування — це не магічне рішення. Воно часто триває довше, ніж планувалося. У підсумку ви змушені підтримувати дві системи одночасно. Ви навіть можете повторити ті самі помилки в новій версії.

Переписування має сенс у таких конкретних випадках:

• Модель даних фундаментально не відповідає потребам бізнесу. • Технологія застаріла і не отримує оновлень безпеки. • Потреби бізнесу змінилися настільки, що оригінальна система застаріла. • Ніхто з поточної команди не розуміє, як працює система.

Навіть у такому разі не робіть одномоментну заміну (big bang replacement). Використовуйте патерн «душителя» (strangler fig pattern). Будуйте нову систему частинами паралельно зі старою.

Здебільшого вам насправді потрібен рефакторинг.

Рефакторинг — це правильний вибір, коли:

• Ви все ще можете додавати нові функції, навіть якщо це відбувається повільно. • Команда розуміє поточний код. • Безлад обмежений конкретними модулями. • Бізнес не може припинити випуск нових функцій.

Перш ніж зробити вибір, запитайте себе, чому код став поганим.

Якщо проблема в технічному боргу, проведіть рефакторинг найгірших частин. Якщо ж проблема у відсутності перегляду коду (code reviews) або поганій культурі розробки, переписування не допоможе. Ви просто створите новий безлад, використовуючи ті самі старі звички.

Поставте собі ці запитання перед прийняттям рішення:

• Чи можемо ми виправити найгірші частини ізольовано? • Чи не є модель даних непридатною для поточних потреб бізнесу? • Які знання ми втратимо, якщо почнемо спочатку? • Чи має бізнес достатню стабільність, щоб пережити тривалий перехідний період?

Початок з чистого аркуша приносить задоволення. Але завершення переписування — це найважча частина. Здебільшого структурований план рефакторингу є безпечнішим і ефективнішим.

Джерело: https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk