Здравствуйте, Lloyd, Вы писали:
L>>>Следовательно, если мы не будем пытаться "заранее выделить код", то взамен ничего не потеряем, сложность уменьшим.
G>>Противоположность увеличения сложности — неувеличение, а не строгое уменьшение. Поэтой при нулевых поползновениях сложность не изменится.

L>Тут не термодинамика, тут любой процесс можно повернуть вспять и очень легко — окрываешь сорсконтрол и делаешь Revert Changes. И если в ревизии 101 у тебя при прочих равных сложность выше, чем в ревизии 100, то откатившись на 100-ю ревизию получишь уменьшение сложности, которого по мнению автора статьи "не существует".

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

А вобще в таких случаях("заранее выделить код") приходится принимать интуитивное решение на основе разумного баланса между противоречиями. Причем противоречия принципиальные неустранимые да еще и в условиях неопределенности.
Есть две поговорки "Быстрее едешь дальше будешь", "Тише едешь дальше будешь" обе из них правильные. Примеры думаю не нужны.

Есть высказывания в XP "Никогда не делай сегодня то, что может потребоваться только завтра". Но это такая же метафорическая поговорка.

При принятии решения о "заранее выделить код" на завтра приходится учитывать.
1) Если при выборе одного из двух решений, потом в случае неудачного выбора откат назад слишком трудоемкий (в сумме труды на первый вариант + переделка на второй). Тогда тут 10 раз надо сначала подумать.
2) Надо пытаться предсказать что потребуется завтра, если пункт 1 заставляет. Причем надо оценить не только вероятности того насколько подойдет вариант, но и сложность создания обоих вариантов, а также перевода одного варианта в другой.Но ясновидцев нет. Только эмпирические интуитивные прогнозы можно делать. И бывает когда они не делаются.
3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь.

Если например у такой фичи слабая связность. int Sqr(unt x){return x*x;}
Если есть подозрения на 50% что потом потребуется более универсальный вариант. Например не в квадрат возводить, а в вещественную степень. То глупо это делать сегодня, подождать пока понадобится.

А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста).
Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
В реальности матожидания рассчитывать невозможно, слишком много факторов, с постоянно меняющимися стоимостями,вероятностями и прочими... Только интуитивные оценки остаются в ральных ситуациях. А в теории можно только обозначить разные факторы, чтоб знать где вобще копать.