Лучшие практики при прототипировании?

Question

При создании прототипов в какой степени вы отказываетесь от лучших практик в пользу взлома кода и исправлений?Разумеется, код не предназначен для хранения в полной версии.

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

Answer 1

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

Если я создаю прототип пользовательского интерфейса, то я выбрасываю все, как только концепция пройдет итерации и будет доказана.

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

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

Answer 2

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

Answer 3

Я выбрасываю «чистые» методы и комментарии (т.е.служебные классы, которые «делают вещи»), но не «бизнес-объекты», если хотите.

Так, например, если у меня есть выбор между определением класса «Car» для определения свойств строкового значения «WheelCount», «DoorCount» или просто созданием быстрой хеш-таблицы, я обычно продолжу и потрачу немного больше времени на создание Класс автомобиля.

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

Самая большая опасность при прототипировании в целом — это думать: «Я исправлю это позже», а затем не делать этого…поэтому, если в ЛЮБОЙ момент вы думаете: «У меня есть довольно хорошее представление о том, как мне нужно провести этот урок», потратьте несколько дополнительных минут на этот урок и сделайте это правильно, чтобы вы могли использовать его повторно.

Answer 4

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

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

Answer 5

Для прототипа действительно важна только внешность.Если вы достаточно смелы, чтобы потом выбросить код, вы можете использовать любой грязный трюк из книги, лишь бы он выглядел великолепно.

Помните, что прототип — это всего лишь инструмент для получения отклика от клиента.(Да, мне это нравится, или почему вы поместили сюда эту опцию?).