паттерн стратегия

[_Bers]

Сообщение от Utkin

В мелкой конторе да, в крупной такой фокус не прокатит.

Так я вам сразу сказал, что это смотря что за коллектив попадется. Что никто никому ничего не должен, коли расписок не давал, и клятв не приносил.

Сообщение от Utkin

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

Под ТЗ я понимаю, "техническое задание" - какая то конкретная текущая задача, которую предстоит решить программисту (артисту, ещё кому то).

То есть, разработку можно рассматривать, как совокупность множества задач. Каждая - своё ТЗ.

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

А документ, который непосредственно описывает поведение (бизнес-логику) приложения на мой бывшей работе назывался "спецификация".

Но не суть. Суть в том, что конечного заказчика не интересуют проблемы программистов. Ему наплевать на все эти сингелтоны/стратегии/медиаторы/фабрики и прочее.

Заказчик заказал себе продукт. А продукт - это работающее приложение, картинка на экране, ну вы поняли.
Что там в программном коде парит только самих программистов.

Сообщение от Utkin

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

Ну во-первых "требования к проекту" к "архитектуре" программного кода имеет ну очень отдаленное отношение.

Допустим, есть требование: кросс-платформа Windows/Linux
Как это может повлиять на архитектуру?
Да ну практически никак. Ну будут некоторые узлы использовать паттерн "пимпл". А используемые внешние библиотеки по возможности кросс-платформенные. Вот и все влияние.

А во-вторых, "фантастическая ситуация: хочу иное" - сплошь и рядом.

Банальный пример: библиотека CEGUI с претензией на игровой GUI.

Это бесплатная оперсорс библиотека, которая несмотря на кучу багов,глюков, и раздолбанный дизайн, тем мне менее практически не имеет альтернативы среди класса "бесплатного ПО".
(её ближайший аналог и конкурент myGUI - те же яйца, только с боку)

Внезапно(!), то есть уже на поздней стадии, когда почти все интерфейсы готовы, выясняется, что она из коробки не умеет выполнять массовый drug-n-drop.

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

Заказчик хочет - заказчик получает.

Разработчик (я и коллеги) - мы залезли в исходный код библиотеки и допилили необходимый функционал.

------------------------------------
На самом деле допиливание чужих движков,библиотек, фреймворков - это довольно частая практика.

[Utkin]

То есть, разработку можно рассматривать, как совокупность множества задач. Каждая - своё ТЗ.

Да, задача с потолка - билинговая система. Соответственно ТЗ будет одно.

А документ, который непосредственно описывает поведение (бизнес-логику) приложения на мой бывшей работе назывался "спецификация".

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

Ну во-первых "требования к проекту" к "архитектуре" программного кода имеет ну очень отдаленное отношение.

Нет такого четкого разделения со стороны заказчика. Это проблемы разработчика.

Допустим, есть требование: кросс-платформа Windows/Linux
Как это может повлиять на архитектуру?
Да ну практически никак. Ну будут некоторые узлы использовать паттерн "пимпл". А используемые внешние библиотеки по возможности кросс-платформенные. Вот и все влияние.

Я бы мог поспорить с Вами, но мы и так сильно отдалились от темы.

Внезапно(!), то есть уже на поздней стадии, когда почти все интерфейсы готовы, выясняется, что она из коробки не умеет выполнять массовый drug-n-drop.

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

заказчик удивился. Он считал, что данная фича - что-то вроде само собой разумеющееся.

Вина разработчика - Вы явно не составили прототип приложения, поэтому заказчик этого не увидел. Заказчик не должен был удивляться, он должен четко понимать, что любые изменения на финальном этапе стоят денег и времени. Очевидно что на встречах с представителями заказчика было уделено мало времени. Мне вообще давали сначала анкету с кучей вопросов. Потом уже встречи и прямое общение.

[_Bers]

Сообщение от Utkin

Да, задача с потолка - билинговая система. Соответственно ТЗ будет одно.

Это не ТЗ.

ТЗ - это техническое задание. Формализованное.
На основе которого можно с закрытыми глазами фигачить код.

"биллинговая система" - это продукт.

Сообщение от Utkin

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

Это и был прототип.

Мы решили, что дешевле будет внести правки в чужую библиотеку, чем менять систему gui, и сливать в ведро все наработки.

Сообщение от Utkin

Заказчик не должен был удивляться, он должен четко понимать

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

[neko3d]

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

Команда номер 1 постутила совершенно верно. А команда номер 2 наплодила такого говнокода, что теперь сами не понимают, кто там есть кто.