"Преждевременная оптимизация — корень всех зол" (Д. Кнут)
Есть на свете хтоническое зло под названием "изделие общего назначения".
Оно возникает там, где требуется решать заранее неизвестные задачи.
Например, когда заказчик-идиот, не озаботившийся составлением ТЗ, встречается с неопытным разработчиком, готовым согласиться на авантюру "напишем ТЗ в процессе".
Программист в этом случае старается заранее подстелить соломки везде, где можно упасть. Что приводит лишь к тому, что вокруг него образуется бесконечное поле граблей, основательно присыпанных соломой.
Парадоксальным образом, в этом случае результат получается лучше у начинающего программиста: его мозги еще находятся в состоянии первородного киселя, и все, что он успевает - описать текущие пожелания заказчика.
Если перед нами более "сильный" программист, он может вступить с заказчиком в великий резонанс идиотизма. И чем выше уровень абстракции, с которым он умеет работать, тем больше идиотизма окажется в проекте.
Джуна спасает то, что он не в состоянии писать (и думать) быстро. Пока он реализует новую фичу, заказчик успевает сообразить, что она ему больше не требуется. Джун много кодит зря, но каждая итерация сама по себе не критична для кода в целом. Выбросить все, что сегодня написали? Ну и черт с ним.
Примерно так же, как "инвесторка, инвестиционная коучница и лесбосепаратистка" может легко отбросить рост личного капитала на 81% за прошедший год (в общей сумме 8100 рублей) и роняя кал ускоренно релоцироваться в Таджикистан.
А развитый программист сначала думает, потом делает. Причем думает долго, а делает быстро.
О чем он думает? Давайте скажем прямо, думает он о том, как бы потом не переделывать готовое, чтобы побыстрее отвязаться о проекта, получить оплату и купить на вырученные деньги золотишка.
Код, написанный мастером - настоящая жемчужина. Нельзя просто взять и выбросить её в песок, если она вдруг оказалась не того цвета. Её нужно сберечь.
Мастер не только пытается предсказать завтрашний ход мыслей заказчика. Он прорабатывает его так, как сам заказчик никогда и не думал. А еще он пытается натянуть новые требования на имеющийся код.
В итоге рождается чудо-комбайн, готовый бесконечно адаптироваться к произвольным требованиям заказчика. Заказчик хотел переместиться из точки А в точку Б? Пожалуйста, ставим в настройках ТипУстройства="Автомобиль" - перед вами Лада Гранта. По дороге придется пересекать горы? Вот тут у нас ушки, к ним можно закрепить воздушный шар и полететь, только не забыть изменить вот эти параметры в настройках.
Заказчик хотел сразу лететь на самолете? Черт. Хорошо, вот вам автомобиль версии 2, у него есть реактивный двигатель. Кстати, ехать на нем все еще можно (только очень страшно).
За время и деньги, потраченные на эту химеру, заказчик давно мог бы получить три специализированных предмета (автомобиль, воздушный шар и самолет), каждый из которых прекрасно выполнял бы свою функцию и не тащил за собой лишнее. Представьте себе размер воздушного шара, поднимающего не только корзину с пассажирами, но и набор колес для езды по дорогам.
Это я еще молчу о том, что ТЗ может быть правильное, и программист не идиот, но проект, разрабатывающийся годами, всегда склонен под флагом повторного использования кода и инфраструктуры обрастать неочевидными связями и решениями.
В конечном итоге, программисту надо не бояться переделывать проект (раз уж требования изменились). Выбрасывать то, что больше не требуется. Оптимизировать именно тот рабочий процесс, который нужен прямо сейчас.
А заказчику, который в целом вообще не в курсе всей этой истории, стоит заранее осознать набор своих хотелок и не полениться записать его на бумажке.
Потому что платить за все эти лишние оптимизации придется из его кармана. И если программист решил, что автомобилю не помешает иметь запасной реактивный двигатель, покрасил его в прозрачный цвет и прикрепил сверху на багажник, то оплачивать дополнительный расход бензина будет заказчик.
