Красной таблетки не существует

Я не раз слышал (в том числе и от уважаемых мной музыкантов), что петь можно научить кого угодно (хотя лучше это делать всё-таки в детстве). Людей совсем без слуха не существует — чтоб человек пел, надо лишь развить то, что и так есть.

Заказчик — вообще основной источник рисков для проекта. Было такое на последней работе. «Field in form should be calculated and editable» — как-то пропустили. А поле вычислялось по сумме по БД. Пришлось для «editable» сумм городить отдельные таблицы.

Ум, как сумма осознанного опыта, даден разработчикам и проектировщикам, как раз, чтобы максимально избежать подобных эксцессов :)

Не согласен, т.к. фраза «динамика роста определенных векторов/осей ответственности» имеет слишком широкую смысловую расплывчатость и не может быть мною корректно формализована.

И потом, это неизбежно, да, ведь разработчик с каждым днем становится профессиональнее, однако рефакторинг ради фана экономически неэффективен. Лучше по-моему поставить задачу так, чтобы рефакторинг понадобился, и фан и польза :) Я совсем не против, рефакторинга, я обожаю удалять код, и если в начала проекта рост строк кода 1-2к в неделю, то к концу проекта добавление функционала, каким-то магическим образом не приводит к увеличению количества кода, напротив, иногда, кода становится меньше.
Золотая середина, я наверное постиг дзен? :)

Чтобы с помощью рефакторинга архитектуру можно было легко скорректировать (на самом деле в достаточно широких пределах) она должна быть покрыта тестами как можно полнее (на крайний случай должна легко покрываться тестами). Для этого архитектура должна быть тестируемой. По-моему, проектировании заранее заведомо легко тестируемой архитектуры, пускай без (пока) намерения писать тесты, как раз тот случай, когда «заранее» не слабость, а сила. Вернее даже превращение слабости, невозможности (объективной или субъективной — не суть) предсказания путей развития проекта, в силу, возможность на этой невозможности не зацикливаться.

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

function updateState($state)
{
  global $USER;

  //...
  mysql_query("UPDATE users SET state = {$state} ... WHERE id = {$USER['id']}";
}

Стало:

function updateState($state)
{
  global $USER;
  $user_id = $USER['id'];

  UserAdapter::updateState($user_id, $state);
}

где UserAdapter::updateState($user_id, $state) проделывает всю работу получая объекты User по user_id и изменяя их состояние, пересекаясь со старым кодом только на уровне данных в MySQL. Сначала UserAdapter стремительно разрастался, но теперь стал потихоньку сокращаться.

Только надо учитывать, что рассказанная история, пропущена через фильтр сознания Ашманова

Конечно. Он и сам это признает в «Эпилог 2.0», отвечая на вопрос:

2) А чего это автор получается весь в белом, а все остальные известно в чём? Или, словами из другого блога, почему автор выходит д'Артаньян, а все остальные персонажи — козлы?

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

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

Ну да, атмосфера — это «практика», которая может стоить дорого :)

Извините, не заметил фразу «без проектирования», думал, вопросы был сколько раз самолёт обычно перепроектируют.

Не все аналогии подходят.

И хреново в нашей отрасли то, что некоторые аналогии приходят извне из общих рассуждений, прямо со студентами. Просто из языка, перевода или созвучности. Т.е. эти аналогии вроде даже насильно специально не навязывают, но как только появляется снова неопытный программист, он повторяет одно и то же.

Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…

Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.

Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).

Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.

А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.

Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.