При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
Собственно вопрос — что дальше? что делать с этим прототипом?
— С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано.
— Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше.
— Переиспользовать часть, часть сделать заново
Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
Алан Купер советует выбрасывать прототип без сожаления.
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Здравствуйте, iZEN, Вы писали:
ZEN>Алан Купер советует выбрасывать прототип без сожаления.
Выбрасывать совсем? Или что-то можно взять? Отдельные классы например. Все переписывать — ну глупо как-то одно и тоже два раза писать, особенно есл одно и тоже получится (это я утрирую конечно).
Насколько целесообразно переиспользовать дизайн, иерархию классов например?
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Ой, старая мозоль
Мне нравится такая методика.
В начале разработки системы выясняются задачи, которые будет решать оная. Т.е. берем юзкейсы (если есть) или просто список функциональных требований, и
стряпаем ГУИ, который и будет отражением этих самых требований.
Короче, первый прототип.
Его можно показывать заказчикам и потенциальным пользователям, чтобы они потрогали его руками. Не представляете, сколько замечаний, поправок и пояснений
получите по поводу функциональных требований! Это здорово, т.к. позволяет заметно снизить риск появления существенных изменений требований в более поздних фазах разработки, когда они будут стоить очень дорого.
Далее.
Изучая и развлекаясь с прототипом №1, анализируем нефункциональные требования. Например, понимаем, что в комбобокс со справочником будет грузиться аж 10000 элементов, и пользователь Вас потом найдет и застрелит Значит, нужно далеть "ленивую" загрузку или просто по частям. Или приложению понадобятся обновления. Или нужно продумать сценарии синхронизации клиентского и серверного кэшей.
Короче, пытаемся просчитать, КАК система будет делать желаемое.
И делаем прототип №2 (а так же №3, №4, и сколько не лень), главное, чтобы в нем не было каши из разных непересекающихся задач.
А теперь рассмотрим, как быть с релизом
Собственно, прототипы и основной проект должны развиваться почти параллельно (основной, понятно, отставать).
Т.е. благодаря прототипу решили проблему, все проверили и резко уменьшили риск, связанный с последующими изменениями — а теперь переносим решение в основной проект. Не "copy&paste" (не вздумайте, а то в релиз попадет мусор и неряшливый код из тестов), а по-новой, вооруженные новым опытом.
В общем, разработка получается хорошо контролируемой, хотя, в первой половине занимает больше времени (до 30%, наверное). Зато, перевалив за середину, проект идет к завершению быстрее за счет гораздо меньшего количества правок, гораздо более ясного кода и случайных ошибок, вызванных поиском причин других ошибок
Теперь о проблемах.
Проблемы будут с малограмотным начальством, которое может увериться, что прототип (даже ГУИ, как не смешно) — это почти готовый продукт. Соответственно, нужно постоянно держать обратную связь с начальством/заказчиком, демонстрирую при помощи прототипов решение конкретных, отдельных проблем и не более того. Ну и ликбез, само собой.
Все в детстве писали сочинения/изложения? Так вот прототип — это черновик.
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, iZEN, Вы писали:
ZEN>>Алан Купер советует выбрасывать прототип без сожаления.
RRM>Выбрасывать совсем? Или что-то можно взять? Отдельные классы например. Все переписывать — ну глупо как-то одно и тоже два раза писать, особенно есл одно и тоже получится (это я утрирую конечно).
RRM>Насколько целесообразно переиспользовать дизайн, иерархию классов например?
Так вот во многом ради выяснения дизайна, архитектуры, и создаются прототипы. Главное, сам код не переносить.
Код в прототипах получается неряшливый, "временный".
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, iZEN, Вы писали:
ZEN>Алан Купер советует выбрасывать прототип без сожаления.
Аналогично Фредерик Брукс еще с 1975 года. В его МЧ-М есть целая глава с названием "Планируйте на выброс". Цитата из начала:
Глава 11. Планируйте на выброс
В этом мире нет ничего постояннее непостоянства.
СВИФТ
Разумно взять метод и испытать его. При неудаче честно признайтесь в этом и попробуйте другой метод. Но главное, делайте что-нибудь.
ФРАНКЛИН Д. РУЗВЕЛЬТ
Опытные заводы и масштабирование
Инженеры-химики давно поняли, что процесс, успешно осуществляемый в лаборатории, нельзя одним махом перенести в заводские условия. Необходим промежуточный шаг, создание опытного завода, чтобы получить опыт наращивания количеств веществ и функционирования в незащищенных средах. К примеру, лабораторный процесс опреснения воды следует проверить на опытном заводе мощностью 50 тысяч литров в день, прежде чем использовать в городской системе водоснабжения мощностью 10 млн. литров в день.
Разработчики программных систем тоже получили этот урок, но, похоже, до сих пор его не усвоили. В одном проекте за другим разрабатывают ряд алгоритмов и затем начинают создавать поставляемое клиенту программное обеспечение по графику, требующему поставки первой же сборки.
В большинстве проектов первой построенной системой с трудом можно пользоваться. Она может быть слишком медленной, слишком большой, неудобной в использовании, а то и все вместе. Не остается другой альтернативы, кроме как, поумнев, начать сначала и построить перепроектированную программу, в которой эти проблемы решены. Браковка и перепроектирование могут делаться для всей системы сразу или по частям. Но весь опыт разработки больших систем показывает, что будет сделано.2 В тех случаях, когда используются новые системные концепции и новые технологии, приходится создавать систему на выброс, поскольку даже самое лучшее планирование не столь всеведуще, чтобы попасть в цель с первого раза.
Поэтому проблема не в том, создавать или нет опытную систему, которую придется выбросить. Вы все равно это сделаете. Вопрос единственно в том, планировать ли заранее разработку системы на выброс или обещать клиентам поставку системы, которую придется выбросить. Если смотреть под этим углом, ответ становится намного проще. Поставка хлама клиенту позволяет выиграть время, но происходит это ценой мучений пользователя, отвлечений разработчиков во время перепроектирования и дурной репутации продукта, которую даже самой удачно перепроектированной программе будет трудно победить.
Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.
...
К этой теме также примыкает другая глава, под названием "Эффект второй системы".
ZEN>Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Вот, цитата из главы резюмирующей все утверждения книги, написанная спустя 20 лет после издания:
Глава 5. Эффект второй системы
5.1 Связь, установленная на ранних этапах и продолжающаяся непрерывно, может дать архитектору верную оценку стоимости, а разработчику — уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.
5.2 Как архитектору успешно влиять на реализацию:
— Помнить, что ответственность за творчество, проявляемое при реализации, несет строитель, поэтому архитектор только предлагает.
— Всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, который не хуже.
— Выдвигая такие предложения, действовать тихо и частным образом.
-Не рассчитывать на признательность за предложенные усовершенствования.
-Выслушивать предложения разработчиков по усовершенствованию архитектуры.
5.3 Из всех проектируемых систем наибольшую опасность представляет вторая по счету; обычно ее приходится перепроектировать заново. 5.4 OS/360 является ярким примером эффекта второй системы. (Похоже, что Windows NT — это пример для 1990 года.)
5.5 Достойной внимания практикой является предварительное назначение функциям величин в байтах и микросекундах.
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
Совсем не обязательно. Это гигантский расход ресурсов.
Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
Все остальное можно сразу начисто писать.
RRM>Собственно вопрос — что дальше? что делать с этим прототипом?
Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
Здравствуйте, AndrewVK, Вы писали:
RRM>>Может сумбурно немного, но интересен у кого какой опыт? Комментарии?
AVK>А с чего ты решил, что есть универсальный образ действий?
Я не считаю, что есть универсальный путь, мне интересно у кого, что было. Как положительный опят так и отрицательный
Здравствуйте, RailRoadMan, Вы писали:
RRM>Я не считаю, что есть универсальный путь, мне интересно у кого, что было. Как положительный опят так и отрицательный
Всяко бывало. От полного копирования прототипа в рабочий проект без изменений до полного переписывания.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, RailRoadMan, Вы писали:
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано.
Все просто! Когда возможно причесать и привести в нормальный вид, то так и надо делать, а если не получается, то писать заново.
Лично я сейчас пишу заново, т.к. прототип написал на динамически типизированном языке.
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
Тут все зависит от случая, я думаю нельзя какой-то единственно верный путь найти. Вообщем здравый смысл рулит
... << RSDN@Home 1.2.0 alpha rev. 786>>
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, iZEN, Вы писали:
ZEN>>Как делалась Windows 95 и как делалась Windows NT? Что в итоге получилось всем ясно.
Кё>Вообще-то NT 3.1 вышла раньше чем Windows 95
Вообще-то, я о том, что Windows 95 унаследовала кучу 16-битного кода от своей предшественницы и плохо масштабировалась. Была ненадёжной.
Windows NT писалась с нуля. Из "прототипа" Windows 95 брались лучшие, обкатанные идеи и переносились в Windows NT. Windows 95 продолжала оставаться прикладным (но не системным!) полигоном для NT-линейки вплоть до объявления о слиянии линеек в одну на основе ядра NT.
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
Угу. Это и называется прототипирование. Но вы же не включаете Unit-тесты в конечный продукт? Или включаете?
MSS>Все остальное можно сразу начисто писать.
Писать можно, но такая фигня получается.
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
Выбрасывать. Или к делу подшивать.
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Не получится.
RRM>>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
Этакий интерактивный Unit-тест на людях.
MSS>И правильно начальство захочет.
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
MSS>Все остальное можно сразу начисто писать.
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
RRM>>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его.
MSS>И правильно начальство захочет.
Ага, а еще такой момент. Прототипирование повторяет идею Test-Driven Development.
Т.е. выяснение, что и как делать, происходит не только (и не столько) на этапе предварительного проектирования, а прямо по ходу дела и по ходу возникновения проблем. Разумеется, когда очередное решение найдено и его архитектура выбрана и опробована "в бою", то это решение еще раз обдумывается, структурируется, соотносится с общей архитектурой системы и переносится в релиз. Заметьте, решение, а не код Код прототипа лучше распечатать и любоваться им издали — так не возникнет соблазна копипастнуть его
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, iZEN, Вы писали:
MSS>>Все остальное можно сразу начисто писать. ZEN>Писать можно, но такая фигня получается.
Что, никогда не бывало такого, что первый запуск после часов кодирования — и каким-то чудом все тесты проходят и все работает корректно?
Здравствуйте, Maxim S. Shatskih, Вы писали:
RRM>>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п.
MSS>Совсем не обязательно. Это гигантский расход ресурсов.
Воспрос о случаях, когда обязательно. Или лучше когда имеет смысл.
MSS>Если есть такие вещи, в реализуемости которых действительно есть сомнения — то их можно на эдаких маленьких юнит-тестиках опробовать.
А если на маленьком юнит-тесте просто не получится попробовать решение. Т.е. нужно сделать достаточну большую систему и только потом станет ясно, что получилось. Кроме того маленький юнит-тест может быть вполне удачным, но не покажет проблем, ктр появятся в реальной большой системе
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом?
MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Тогда это уже не прототип, а версия v0.1
Кроме того начисто писать прототип -> тратить гораздо больше времени -> результат от прототипа получен позже -> позже может выяснится, что использованный дизайн неудачен, а это вполне возможно, ради проверки прототип затевали
RRM>>Собственно вопрос — что дальше? что делать с этим прототипом? MSS>Его надо было с самого начала писать так, чтобы стало уже навсегда, если получится.
Арабская мудрость гласит: "Чтобы сделать что-то хорошо, нужно сделать это как минимум дважды". Так вот писАть "сразу и навсегда" это имхо из разряда "in the perferct world" — было бы замечательно, и менеджеры были бы довольны — сильно упростилось бы у них планирование проектов — но в большинстве случаев у реальных разработчиков не получается.
Здравствуйте, RailRoadMan, Вы писали:
RRM>При разработке какой-либо сложной системы создается прототип, чтобы понять, как лучше делать, какие проблемы могут вылезти и т.п. И вот прототип готов, все более менее получилось с точки зрения подхода, грабли прояснились, куда дальше двигаться понятно
RRM>Собственно вопрос — что дальше? что делать с этим прототипом? RRM>- С одной строны можно его же причесывать и приводить в состояние, когда его можно назвать продуктом. Весьма заманчиво, так как многое уже сделано. RRM>- Выкинуть нафиг и сделать заново очитывая при дезайне полученный опыт. Тут много надо сделать заново — потребуется больше времение, но что-то можно делать лучше/существенно лучше. RRM>- Переиспользовать часть, часть сделать заново
RRM>Может сумбурно немного, но интересен у кого какой опыт? Комментарии? RRM>Опять же начальство может не захотеть отказываться от прототипа и додедывать именного его. Какие аргументы могут быть против?
теория говорит — реюзать полученые в ходе прототипирования знания, а не код. на практике практически всегда реюзал и код. и думаю это была ощибка, его стоило переписывать. "доделывать" прототип будет ошибкой.
