Чистота кода. Синусоида рефакторинга. Неожиданно о коде

Сначала ты пишешь чистый, но не особо функциональный код. Потом переделываешь и материшься. Либо пишешь всё сразу абы как, а потом, уже оттестив, получив уточнения по тз, приводишь всё в порядок.

Ясное дело, что стремится надобно к идеалу, но подход *уйня, но работает 20 фич, в большинстве случаев выигрывает в бизнесе перед подходом отлично, но 1 фича. (Исключения есть, но обычно они находятся в высокорисковых областях новых рынков).

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

Написали кучу рабочего шлака, привели в порядок, написали ещё кучу, привели. Технический долг такое дело, хуже кредита в известном банке не чистом на руку.

С таким подходом на первый план выходит толковая архитектура, а не чистота кода в процессе разработки. Закладываемая на первых парах структура должна иметь приемлемый уровень пластичности.

Лучше потратить чуть больше времени на продумывание архитектуры, чем на чистоту кода при первых итерациях.

Остальное так, процесс производства, ребят)