Коротко. Чтобы "писать код".... Надо садиться и "писать код"

Чтобы "писать код".... Надо садиться и "писать код".

А не тереотизировать на тему "как будет здорово построить мост".

"Тупо" САДИТЬСЯ и ПИСАТЬ. БЕЗ затей.

Просто "тупо писать".

И СТРЕМИТЬСЯ "выполнить поставленную задачу".  И не думать про "постройку моста".

"Код не понравился" - это НЕ ПОВОД не писать код вообще.

ЗАДАЧУ, надо СНАЧАЛА закрыть "как есть", а ПОТОМ - написать ЗАДАЧУ на РЕФАКТОРИНГ особенно, когда ТЕРЯЕТЕ ТЕМП.

А не тянуть вола за хвост.

И НЕ НАДО "сферических коней" на "будущее". Будущего у сферических коней - НЕТ.

Есть код, есть тесты, есть рефакторинг. Есть ТЗ в конце-концов. Всё.

НИКАКИХ "коней".

ВСЕ "фреймворки" и "обобщения" ДОЛЖНЫ БЫТЬ выстраданы в ЕЖЕДНЕВНОЙ разработке и БОРЬБЕ с РЕАЛЬНО повторяющимся кодом.

Ну и если "забываете" - ЗАПИСЫВАЙТЕ,

И ещё - "в НАЧАЛЕ дня СТАВИМ себе ЦЕЛЬ, в КОНЦЕ дня - ОЦЕНИВАЕМ насколько мы эту цель выполнили".

Собственно всё.

P.S. если "задача сложная", то ТЩАТЕЛЬНО и РЕГУЛЯРНО коммитим и ТЩАТЕЛЬНО документируем КАЖДЫЙ коммит - Черновик. Вариации на тему TDD.

И ОЦЕНИВАЕМ тот факт - КАК МЫ ДВИЖЕМСЯ к цели. И ДВИЖЕМСЯ ЛИ.

P.P.S. Это всё "напоминает" Agile. Но! Лишь "напоминает".

Ибо "водопадную модель" - НИКТО НЕ ОТМЕНЯЛ.

Процитирую: "ТЗ — это большое БЛАГО для программиста. „Водопад“ — возможность творчески работать, не загоняя себя в угол."".

Но!

"Огонь и движение" (и Agile) - ЛОКАЛЬНО, и "водопадная модель" - ГЛОБАЛЬНО.

P.P.P.S. И ещё...

Пишите тесты.

Процитирую самого себя:

"Пишите тесты. Обязательно пишите. Это поможет вам чувствовать уверенность в завтрашнем дне. Чтобы быть уверенным в том, что код и вся архитектура не развалится завтра при случайной правке базового класса или внесении правок в ТЗ.".

P.P.P.P.S. И ещё...
Если кнопка называлась "Выделить", а стала называться "actSelectAll" (в результате "рефакторинга"), и вы ПОКОММИТЕЛИ "это" и "это" ПРОДОЛЖАЕТСЯ несколько НЕДЕЛЬ, то вы ПЛОХО сделали своё дело.