Вот такой вопрос -- допустим надо сделать прототип приложения, ибо не ясно кому и зачем это может пригодится. Так уж ли необходимо обращать внимание на всякие мелочи и делать сразу правильно -- т.е. где необходимо хранить состояние, делаем соотв. таблицу и пишем код для работы с этим состоянием. Ну и т.д.
Пример,клиент получил какой-то важный результат и отправляет его в очередь дальше (rabbitmq). По-хорошему, для начала полученный результат надо сохранить в базе. И вероятно, при дальнейшем развитии проекта это будет сделано. Но на этапе прототипирования не проще ли на это временно закрыть глаза и сразу отправлять в очередь?
Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
PS:Я имею в виду именно детали, а не основную задачу, которую решаем.
Здравствуйте, Sharov, Вы писали:
S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
Можно и не делать. Но надо бы убедиться, что когда дойдет до продакшена, это хоть в принципе будет сделать можно.
Как убедиться — отдельный вопрос. Кому-то хватает внутреннего убеждения, кому-то будет проще, если это сохранение в базе сделать хоть в виде пустых функций-заглушек, а кому-то понадобится игрушечную базу прикрутить.
Здравствуйте, Sharov, Вы писали:
S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
Имхо, только если одной из целей прототипа было проверить "отказоустойчивость, надежность и проч."
Т.е. если задачей было оценить выбранные интерфейсные решения, то, даже делать сколько-нибудь близкий к реальному слой данных не стоит — пусть будут статические данные зашитые прямо в страницу (если мы о Web-решении).
Беда прототипов, с которыми я сталкивался, (помимо того, из них часто пытаются вырастить нормальное решение "вот ведь, уже почти всё готово"), что на него нет четкого scope и цели — что именно мы хотим проверить, а что или не будем проверять или проверим на другом примере. Прямо по пунктам.
Из-за этого сроки прототипирования растут ("а давайте еще и вот это посмотрим — ведь у нас есть прототип!"), когда становится много, код обрастает костылями ("это же прототип, сейчас надо быстрее, а потом всё с 0 напишем"), времени и денег становится жалко, да и на основной проект почти не осталось...
Имхо, цели прототипирования должны быть прописаны даже четче, чем у основного продукта, ибо срок разработки прототипа должен быть минимальный, а на выходе мы должны четко понимать каков результат — положительный или отрицательный (и нужно делать другой прототип).
Здравствуйте, Sharov, Вы писали:
S>Вот такой вопрос -- допустим надо сделать прототип приложения, ибо не ясно кому и зачем это может пригодится. Так уж ли необходимо обращать внимание на всякие мелочи и делать сразу правильно -- т.е. где необходимо хранить состояние, делаем соотв. таблицу и пишем код для работы с этим состоянием. Ну и т.д.
... S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
А как цель прототипирования сформулирована ? Какие проблемы ты хочешь решать прототипом ? В прототипе обычно нет таких вещей, как обратная совместимость. Соответственно прорабатывать не нужно, вообще, нисколько.
Если же цель прототипа связана с этой обратной совместимостью, то все ровно наоборот. Например, есть гипотеза "новый апи, который будет обратно совместим со старым и даст адский перформанс даже старым клиентам". Её можно подтвердить, опровергнуть прототипом. Достаточно обеспечить две вещи — перформанс и обратную совместимость. Вот здесь срезать углы нельзя, ни разу.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А может надо просто не использовать очереди, хранение в которых ненадежно?
Это выбор архитектора, с которым я в целом согласен. Нам важна асинхронность. Вообще не это я хотел бы обсудить.
Очередь была как пример. Т.е. после получения результата на клиенте и его сохранением в дюрабельную очередь сообщение может изчеснуть -- клиент упал или до очереди не дошло. Я, допустим, просто отправляю результат сразу в очередь и не парюсь с надежностью. Для прототипа такая минималистичная фунц-ть мне кажется нормальной.
Здравствуйте, Sharov, Вы писали:
S>Это выбор архитектора, с которым я в целом согласен. Нам важна асинхронность.
Какая связь между асинхронностью и надежностью хранения?
S>Очередь была как пример. Т.е. после получения результата на клиенте и его сохранением в дюрабельную очередь сообщение может изчеснуть -- клиент упал или до очереди не дошло. Я, допустим, просто отправляю результат сразу в очередь и не парюсь с надежностью. Для прототипа такая минималистичная фунц-ть мне кажется нормальной.
Ответ очень простой — надо седовать текущим требованиям. Если требования требуют гарантии доставки, а ваш архитект зачем то выбрал решение, которое этому мещвет, то надо флаг в руки и вперед, вставлять костыли. Если здесь и сейчас такого требования нет — ничего сейчас делать не надо, но код надо писать так чтобы добавление такого требования не потребовало переписать его половину.
Здравствуйте, Михаил Романов,
МР>Беда прототипов, с которыми я сталкивался, (помимо того, из них часто пытаются вырастить нормальное решение "вот ведь, уже почти всё готово"),
Вот в 90% случаев (или даже больше) проблема прототипа именно в этом и заключается — манагеры (те, которые руками водители), увидев прототип, радостно бегут к клиенту и продают его с радостными воплями "у нас уже все готово!" А потом закономерно получается продукт по принципу "херак-херак и в продакшен!" — потому что "пилите быстрее, да пофиг на качество, мы уже продали продукт! сроки горят!!!".
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Какая связь между асинхронностью и надежностью хранения?
Никакой.
НС>Если здесь и сейчас такого требования нет — ничего сейчас делать не надо, но код надо писать так чтобы добавление такого требования не потребовало переписать его половину.
Здравствуйте, Sharov, Вы писали:
S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
настолько, насколько позволяют сроки на прототип.
в зависимости от цели прототипа: узкий тест или широкая имитация финального продукта.
Здравствуйте, Sharov, Вы писали:
S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.?
Это определяется исключительно целью создания прототипа.
Здравствуйте, Sharov, Вы писали:
S>Т.е., насколько при прототипировании нужно сползать в детали и делать все по науке -- отказоустойчивость, надежность и проч.? S>PS:Я имею в виду именно детали, а не основную задачу, которую решаем.
Вообще не надо. Прототип должен решать поставленную перед ним задачу и точка. Самыми простыми и быстрыми средствами.
Но. У бизнеса, увидевшего готовый прототип всегда возникает желание сказать "ну вот у вас уже все работает, давайте докрутите UI на коленке и через месяцок в прод". И тогда становится больно и грустно. Поэтому важно правильно скоммуницировать этот момент заранее. И перед продакшном выкинуть весь код от прототипа, выдрав куски важнейших флоу.
Все зависит от целей прототипа.
Если цель прототипа показать UI. Тогда достаточно все данные хранить в памяти. Но для того, что бы прототип не был мусорным, а был более-менее эволюционным, желательно вынести поставщиков данных в отдельные классы с интерфейсами или абстрактными классами, и использовать интерфейсы и асбтрактные классы, вместо самих классов, но не надо прикручивать IoC и фабрики, который будет создавать необходимые экземпляры классов, на пример.
В общем нужно делать функционал необходимый функционал для прототипа + мин. затраты на то, что бы заглушки и стабы правратить в реальные поставщики данных. Но тут опять же... На сколько горят сроки и нужен ли эволюционный прототип с абстракциями или достаточно весь код в Main() и показать результат? На этот вопрос отвечать только тебе.
В принципе лакмусовой бумажкой может быть факт: на сколько понятно чего хочет сам заказчик? Если заказчик "плавает" в требованиях и не может четко сформулировать свои желания, то лучше не заморачиваться с эволюционным прототипом. Если же есть более-менее четкие требование, то лучше разрабатывать эволюционный прототип.
