🧠 Код должен становиться лучше. Но когда?

Сегодня предлагаю поразмышлять: код должен становиться лучше? И если да - то когда?

Рефакторинг - штука полезная. Но не всегда нужная.

Вот мой ответ: Улучшать код стоит только там, где есть реальная боль. Писать код хорошо - всегда!

А теперь по порядку.

Из опыта

Первый случай. Однажды было принято решение переделать сложную систему «Х» с нуля. Сделать красиво - выделить сущности, подготовить интерфейсы, фабрики, стратегии. Разработка затянулась. Стоимость работы начала превышать получаемую выгоду. Заказчик сказал: «Стоп».

Второй случай. Код был написан 5 лет назад. И прекрасно работает, выполняет свою задачу. О нём вспомнили, когда решили обновлять компонент логирования.

В первом случае мы рефакторили то, что работало. Без реальной потребности. Просто «чтобы красиво». Это ошибка.

Во втором случае код работал и не болел - его и не трогали. Это правильно.

Когда стоит улучшать?

Прежде чем что-то улучшать, задай себе вопрос: зачем?

Эта система реально болит? Она мешает? Она тормозит развитие?
Если да - тогда думаем, как рефакторить.
Если нет - не трогаем.

«Хочется сделать красиво» - это не причина. Красота ради красоты - это развлечение. Развитие ради развития - это потеря времени.

Рефакторить нужно там, где без этого уже никак. Там, где код начинает обращать внимание сам на себя - тормозит, путает, ломается. Где каждое изменение - это боль и риск.

🎯 Мой подход сейчас

К текущему моменту может показать что я отговариваю от хорошего кода, но не спеши с выводами.

Мой подход - сразу делать хорошо! Это не про «переписывать всё подряд». Это про базу. И да - это возможно.

Ещё раз. Без тренировок. Без отдельного времени на рефакторинг. Вот так - сел решать продуктовую задачу, и твой код стал лучше вместе с решённой задачей.

Каждая новая задача - это вызов. Как закрыть задачу и сделать код понятнее с минимальными затратами?

Как это совмещается?

Первая часть статьи - про осознанность. Не рефакторить ради рефакторинга. Не трогать то, что работает и не болит.

Вторая часть - про навык. Когда ты уже умеешь писать чистый код, ты делаешь это сразу. Без отдельного времени на рефакторинг.

📌 Нужно - писать код сразу хорошо, приближайся к этой идее с каждой задачей, с каждым ревью твоего кода коллегами.

Где можно и нужно экспериментировать

В своих проектах. Вдали от продуктовых задач и работы.

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

А в рабочем коде - только по делу. Только там, где это реально нужно.

🔥 Как сразу делать хорошо?

Если у тебя задача например "добавить новый метод API", сразу продумай:

DTO - чтобы данные ходили не абы как, а понятными объектами
Валидаторы - чтобы не ловить потом мусор в сервисах
Репозитории - чтобы работа с данными была в одном месте, а не по всему коду

И главное - следуй общей структуре проекта, согласованной в команде.

Сразу оговорюсь... Если не умеешь или не уверен - не выдумывай велосипед. Просто следуй стилю и структуре текущего проекта. Так ты не привнесёшь путаницу и новые странные структуры в легаси.

Сделал чисто - молодец. Сделал в едином стиле - золото.

Итог

Ситуация	Что делать?
Старый код работает и не болит	Не трогать
Старый код болит (тормозит, путает, ломается)	Рефакторить поэтапно и планомерно
Новый код	Писать сразу хорошо
Эксперименты с архитектурой	В своих проектах
Бизнес-задача	Решать эффективно, но стремиться к подходу «делать сразу хорошо»

👇 А ты как решаешь? Рефакторить код или оставить простым? Обсуждаем по ссылкам ниже 👇

💬 Обсудить пост:

🔥 И не забудь подписаться :)