Dev Easy Notes

Когда делать рефакторинг?

Вопрос от подписчика. Кстати, если у вас есть интересные вопросы для разбора, можете писать в личку канала.

Я не буду рассказывать про конкретные методы рефакторинга — об этом есть куча статей и книг. Просто поделюсь тем, как обычно подходят к этому процессу в некоторых командах, в которых я работал.

В разработке главное противостояние — между бизнесом и разработчиками. Бизнесу важно сделать как можно больше фич, чтобы захватить больше рынка, а разработчикам нужно, чтобы писать код было комфортно, в том числе с использованием новых технологий. Если произойдет перекос в любую из сторон, будет жопа.

Если перекос в сторону бизнеса, стоимость внедрения фич улетит в космос. Если победит разработка, мы будем бесконечно рефакторить код чтобы сделать идеально, спорить о важности SOLID и переписывать всё на новые UI-фреймворки.

Важно соблюдать баланс. Поэтому для проведения рефакторинга нужны четкая цель и причина. Нужны метрики, по которым будет понятно, что рефакторинг необходим. Например: График времени выполнения похожих задач — если он растет, значит, что-то не так с техдолгом. Не всегда это можно отследить, поэтому могут быть чисто технические метрики:

👉 Архитектурные ограничения — из-за текущей архитектуры мы не можем использовать что-то, кроме UI-тестов. Метрика: количество не-UI тестов.
👉 Отсутствие навигации — из-за этого онбординг новых разработчиков занимает дни, а код-ревью превращается в хаос. Метрика: время на ревью, время онбординга.
👉 Ненадежные тесты — текущая библиотека для тестов сильно флакает. Метрика: количество флакающих тестов.

Это если мы говорим про рефакторинг, который идет от разработки. Но иногда он может идти сверху: "У нас в компании обновилась библиотека для полей — нужно перейти на новую версию для консистентности UI."

Короче, для действительно нужного рефакторинга важны:
👉 Четкая цель
👉 Измеримые метрики
👉 Минимальный roadmap (как внедрять изменения постепенно)

Как именно проводить рефакторинг — зависит от задачи и конкретной ситуации в проекте. Есть вот такой доклад пятилетней давности на эту тему. Насколько помню, в нём было много крутых советов.

www.tgoop.com/dev_easy_notes/470

1.7K viewsedited  Jun 25 at 09:23

Когда делать рефакторинг?

Вопрос от подписчика. Кстати, если у вас есть интересные вопросы для разбора, можете писать в личку канала.

Я не буду рассказывать про конкретные методы рефакторинга — об этом есть куча статей и книг. Просто поделюсь тем, как обычно подходят к этому процессу в некоторых командах, в которых я работал.

В разработке главное противостояние — между бизнесом и разработчиками. Бизнесу важно сделать как можно больше фич, чтобы захватить больше рынка, а разработчикам нужно, чтобы писать код было комфортно, в том числе с использованием новых технологий. Если произойдет перекос в любую из сторон, будет жопа.

Если перекос в сторону бизнеса, стоимость внедрения фич улетит в космос. Если победит разработка, мы будем бесконечно рефакторить код чтобы сделать идеально, спорить о важности SOLID и переписывать всё на новые UI-фреймворки.

Важно соблюдать баланс. Поэтому для проведения рефакторинга нужны четкая цель и причина. Нужны метрики, по которым будет понятно, что рефакторинг необходим. Например: График времени выполнения похожих задач — если он растет, значит, что-то не так с техдолгом. Не всегда это можно отследить, поэтому могут быть чисто технические метрики:

👉 Архитектурные ограничения — из-за текущей архитектуры мы не можем использовать что-то, кроме UI-тестов. Метрика: количество не-UI тестов.
👉 Отсутствие навигации — из-за этого онбординг новых разработчиков занимает дни, а код-ревью превращается в хаос. Метрика: время на ревью, время онбординга.
👉 Ненадежные тесты — текущая библиотека для тестов сильно флакает. Метрика: количество флакающих тестов.

Это если мы говорим про рефакторинг, который идет от разработки. Но иногда он может идти сверху: "У нас в компании обновилась библиотека для полей — нужно перейти на новую версию для консистентности UI."

Короче, для действительно нужного рефакторинга важны:
👉 Четкая цель
👉 Измеримые метрики
👉 Минимальный roadmap (как внедрять изменения постепенно)

Как именно проводить рефакторинг — зависит от задачи и конкретной ситуации в проекте. Есть вот такой доклад пятилетней давности на эту тему. Насколько помню, в нём было много крутых советов.

BY Dev Easy Notes