18-я веснаБывало ли у кого-то такое, что постановка, ТЗ сделаны настолько близко к реальным нуждам заказчика, что после окончания кодирования и внутреннего тестирования - при внедрении, не требовалось бы вносить изменения в исходное ТЗ и соответственно переделывать код?
Хм. Вопрос опирается на предположение о том, что реальные нужды заказчика не меняются в ходе разработки, что малоправдоподобно.

У меня нечто подобное было в одном проекте, со следующей спецификой:

1. Это программа для инженеров сотовой связи. Пользовалось ей довольно мало народа (один отдел), причем народа технического, четко знающего свои задачи и способного их сформулировать.

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

3. Программа таки была достаточно небольшой (меньше 100'000 строк).

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

18-я веснаПочему же они должны поменяться?
Почему они не должны меняться?

18-я веснаМожет Вы их перепутали с озвученными требованиями?
Нет, это неинтересно. С озвученными требованиями все просто - если мы не смогли понять, что же на самом деле нужно клиенту, придется искать методом проб и ошибок (то есть перерабатывать софт). Вывод тоже понятен - улучшать работу на этом этапе. Трудно? Да. Но в целом ясно, кто виноват и что делать.

А вот изменение реальных требований - процесс, который от нас практически не зависит ¹ . Поэтому и изменения, которые в силу этого требуется внести, носят объективный характер. И пока мы не разберемся с ними, говорить "можем ли мы вообще избежать изменений" бессмысленно.

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

18-я веснаА реальные требования заказчик в большинстве случаев не способен сформулировать.
Из этого не следует, что они постоянны.

Обратите внимание, в описанном мной случае они именно такими и были - поскольку опирались не гуманитарщину, а на физику. Легко изменить процесс продажи, гораздо труднее изменить хождение радиоволн :)

18-я веснаЭто как раз мне кажется обратный случай - ТЗ писалось и кодирование шло по результатам внедрения :)
Не "писалось", а "детализировалось". Более формально - детальная спецификация составлялась не в начале проекта, а в начале работы над очередным модулем.

Кстати, это вообще весьма уважаемый мной принцип - не делать работу заранее. Весьма помогает избегать ситуации "работа сделана напрасно и существенно не так, как надо".

18-я веснаТак что Ваш пример не подходит.
Ну, это уже Вам виднее. Другого у меня нет.

18-я веснаЕсли заведомо известно, что все равно надо будет что-то переделывать,
Именно так.

18-я веснато надо проектировать код так, чтобы легко можно было вносить изменения (иногда существенные) в структуру кода.
Полностью согласен.

18-я веснаДругими словами это означает увеличение расходов на первоначальное проектирование,
В принципе можно было бы согласиться, но не соглашусь, причем по субъективным причинам. Их две.

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

Во-вторых, я уверен, что при определенном опыте, "набитой руке" на соответствующие подходы, выработанном инструментарии такую "устойчивую к изменениям разработку" можно вести очень дешево, практически бесплатно относительно "обычной".

[У меня как у мисс Марпл есть привычка по любому поводу вспоминать предыдущий опыт]. Так вот, в этом случае я вспоминаю систему, сделанную не мной на одной из предыдущих работ. В итоге она была внедрена у трех заказчиков - и дважды кардинально переделывалась. В то же время там есть модуль, который я разработал, и который внедрен никак не в меньшем количестве мест, наверняка в большем (не знаю точно, поскольку он жил после моего ухода, вполне вероятно живет и до сих пор). Этот модуль был спроектирован именно под адаптацию к конкретным заказчикам; первые пару адаптаций делал я, потом ушел - в итоге, года через три меня один раз попросили сделать то, что они не хотели трогать. Я сделал, за день. Обнаружив при этом кучу мелких доработок в целом в предусмотренных направлениях и практически неизменный код "ядра" - его настолько не требовалось трогать, что когда таки потребовалось, позвали меня.

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

18-я веснаТакая ситуация (итеративность дизайна) декларируется в экстремальном программировании, однако остается и классика - полное ТЗ + кодирование.
Из умных книг мне вспоминается слово waterfall, которое нынче дружно ругают.

Как ни странно, современные работы по проектированию трогают меня довольно мало. Бывают любопытные мысли, но в целом читать их скучно, ощущение deja vu. Из тех факторов, которые я могу выделить как оказавшие на меня серьезное влияние, большую роль играет читанная в детстве старая книга http://www.libex.ru/detail/book59509.html В частности, когда я впервые читал про экстремальное программирование, изложение разделилось на две четких группы мыслей: "похоже на Йодана" и "бред какой-то" :)

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

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

18-я веснаНо если окажется, что и при классическом проектировании дефакто в каждом (в 100% случаев) проекте есть несколько итераций
дизайна
Практически в любом живом проекте. В самой что ни на есть классике таки предусматривается стадия сопровождения, которая по сути и есть итерирование дизайна. Отличие современных проектов в том, что такое итерирование чаще всего оказывается необходимым до сдачи в экспуатацию. Что вполне понятно - в "классические" времена задачи были много проще, а их постановка делалась относительно более тщательно (относительно - в смысле "потраченные силы" / "объем задачи").

18-я веснаСогласен. Но здесь скорее всего все-таки возникают новые требования, а не меняются старые. Что-то типа "аппетит приходит во время еды" :)
"Аппетит приходит во время еды" - удачное описание для большинства изменений этого типа.

И возникают новые, и меняются старые, но вопрос не в этом. Даже возникновение нового требования часто приводит к модификации старого кода. Не просто к созданию нового куска, но к изменению реализованного.

Just for example, опять же из практики. В организации было множество складов, причем склады были нескольких типов (по смыслу и по операциям, которые там выполнялись). Большинство складов обслуживалось программой А, один тип складов обслуживался программой Б. Их СУБД реплицировались и были похожи, но не одинаковы (практически, в незапамятные времена текущую на тот момент версию программы А обкарнали, доработали напильником и сделали Б. Потом некоторые изменения из тех, что делались в А, вносили и в Б, опять же дорабатывая напильником).

Изначально была поставлена задача написать программу В, работающую на той же БД, что и А, и обслуживающую некий тип склада (в итоге В должна была заменить А, это была первая итерация). Она была сделана и внедрена. В ходе работ была поставлена задача написать также программу Г для замены Б; эта задача также была решена, причем что вполне естественно, с максимальным использованием решений из В. После чего, полюбовавшись на неосторожно добавленные нами в Г "мощные" решения из В и вспомнив, как плохо все было в Б, нас спросили: а можно ли добавить в Г всю функциональность В, а заодно убрать ряд ограничений, которые разработчики Б выбили, чтобы облегчить себе жизнь? Как Вы понимаете, ответ был "можно". Но! То, что мы писали в В, мы писали для определенного типа склада и с ограничениями и заглушками, свойственными этому типу. И если бы мы не держали в уме, что В потребуется дорабатывать для других складов, если бы облегчили себе жизнь так же, как когда-то сделали разработчики Б - пришлось бы нам вносить баальшие изменения.

18-я веснаСейчас как раз и занимаюсь уговорами, но мое начальство считает свой опыт единственно правильным :)

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

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

18-я веснаХотелось бы по ходу обсуждения услышать, кто какие методы применяет для минимизации редизайна. Например: система плагинов, скриптовый язык, и т.д.
Названное вторично, если не третично, имхо.

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

Второй ключевой фактор - наглядность, очевидность решения. Вы совершенно справедливо отметили, что менее квалифицированные продолжатели без проблем испортят хорошую вещь. Я не готов сформулировать рецепт, но полагаю, чтобы избежать этого, необходимо, чтобы буквально бросалось в глаза: ЭТУ ЗАДАЧУ, ЕСЛИ ПОТРЕБУЕТСЯ, НУЖНО РЕШАТЬ ВОТ ЗДЕСЬ. В противном случае будет трудно избегать деградации.

Система плагинов имеет свои плюсы и свои минусы. С точки зрения темы стоит отметить, что плагины неизбежно требуют определенного уровня модульности и вынуждают четко проектировать и поддерживать интерфейсы взаимодействия (также одна из ключевых мыслей Йодана). Кроме того, малоквалифицированные программисты легко могут испортить "цельную" программу, протянув "левые" связи между ее компонентами; с плагинами это намного сложнее.

Скриптовые языки... к подобным вещам я отношусь весьма неодобрительно. С моей точки зрения, это отличный способ вбухать довольно много сил с крайне плохим результатом, либо вбухать еще намного больше сил с довольно средним результатом. Грешен, сам однажды сделал, но там были крайне слабые требования, и написать интерпретатор строк на сто было явно проще и удобнее других вариантов. Мне нравится следующий подход:

1. Изначально модули пишутся нормальным образом, с использованием обычного ЯП.

2. В нужных местах закладывается возможность конфигурирования. Сначала примитивного, так, чтобы хватило решить текущие задачи. Подчеркну: не "задумывается и реализовывается нечто глобальное", а "скромная задача решается так, чтобы по необходимости ее без проблем можно было развить в глобальную".

3. Со временем типовые решения дорастают до конфигурируемости, практически исключающей необходимость писать код для решения этой задачи.

grexhideДругое дело, что не все так страшно, и при должном навыке и опыте (профессионализме) разработчики поступают проще: долго и нужно реализуют концепции вида (при наличии терпения и понимания со стороны руководства):
Именно так и появляется продукты, нуждающиеся в переделке еще до завершения разработки. Сначала долго уговариваем подождать, потом долго работаем, не имея обратной связи, и наконец пытаемся уговорить, что сделанное - именно то, что требовалось.

iscrafmСитуация "вместо редизайна производится quickfix, латание дыр" - типовой путь к глюковатым монстрам. С этим нужно бороться любыми методами.
Воистину так.

Можно говорить, что инженерная работа - непрерывный поиск компромиссов, но качество - та категория, где нет места компромиссам.