А действительно, зачем?
🟢 Программисту больше работы и усилий, чтобы сделать код лучше.
🟢 Компания оплачивает время, пока разработчик улучшает старый код вместо внедрения нового функционала.
Если смотреть на разработку с такой стороны, то, конечно, рефакторинг не нужен, нас пытаются нагреть, расходимся. 😱
Но если посмотреть глубже, то мы увидим такую последовательность:
1️⃣ пишем плохой код
2️⃣ через какое-то время внедряем новую фичу, при этом пишем плохой код
3️⃣ повторяем п.2 несколько раз
4️⃣ при попытке внедрить новую фичу программист заявляет, что ему потребуется вдвое больше времени, потому что плохой код и разбираться нужно
5️⃣ повторяем п.2 несколько раз
6️⃣ при попытке внедрить новую фичу программист заявляет, что это невозможно, потому что придётся переписывать половину кода
❗️Если же следить за кодом, хотя бы в минимальной форме, без фанатизма, то новый функционал можно будет внедрять гораздо легче, а значит приложение будет оставаться поддерживаемым и расширяемым гораздо дольше.
А ещё плохой код часто работает медленнее. Где-то вызовы дублируются, где-то память утекает, и т.д.
Помимо этого бывают кейсы (однажды сам такой создал): после тяп-ляп-разработки появились несколько идентичных кусков кода в разных местах.
Жили они спокойно, а потом было несколько итераций изменений, и как вы понимаете, эти изменения дошли не до всех фрагментов, затерявшись по пути.
Код стал работать по-разному, поэтому пришлось наводить порядок и производить «извлечение метода».
✅ Лично я вижу прямую выгоду для бизнеса в том, чтобы потратить на пару процентов больше времени и сделать нормально, а не тяп-ляп.
А есть ли исключения?
Конечно же бывают кейсы, когда скорость разработки важнее поддерживаемости, например при создании прототипа или MVP.
Тут немного другие законы: важно как можно раньше выпустить продукт и проверить будет ли он вообще востребован рынком
Оригинал статьи в моём ТГ канале https://t.me/teamlead_monday/9