В чем разница между прототипом и решением на уровне производства?

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

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

1. Модульное тестирование каждого метода
2. Обеспечение покрытия кода ~ 100%
3. Регистрация всех исключений и возможных указателей - возможно с AOP
4. Использование шаблона проектирования интерфейса, внедрение зависимостей, возможно, с использованием фреймворка, например spring.net
5. Использование счетчиков производительности и профилировщиков для измерительных приборов
6. Применение соответствующей безопасности - то есть проверка подлинности Windows (если это требуется клиентом).
7. Управление транзакциями по каждому методу
8. Резервное копирование файлов веб-приложения перед новым развертыванием решения

Что еще?

Мой вопрос больше связан с технической стороной, а не с функционалом / документацией, потому что иначе мы пойдем по другому пути :-)

Спасибо.

Я думаю, что наиболее важным отличием является то, что цель прототипа состоит в следующем:
1. Доказать, что проблема может быть решена определенным образом ИЛИ
2. Дать клиенту / руководству представление о том, как будет выглядеть и ощущаться продукт

тогда как целью живой системы является:
1. Решить определенную проблему / решить проблему.

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

Это также потому, что прототип, как правило, является «быстрым и грязным» проектом, объединенным без каких-либо соображений, которые вы правильно указали в своем вопросе (таких как тестирование, производительность, безопасность и многое другое).
Так что вам лучше начать новый, правильный проект, чем пытаться сделать плохой проект лучше.

Не все эти вещи требуются, в зависимости от ваших требований, или может потребоваться больше. Если вы понимаете, что я имею в виду;) Модульное тестирование и покрытие кода - это хорошие вещи, но в зависимости от того, как вы выполняете другие части процесса, может не потребоваться. Кто-то скажет, что для профилирования производительности важнее хорошо документированный код или учебное пособие. Различается!

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

Использование счетчиков производительности и профилировщиков для контрольно-измерительной аппаратуры ... может быть целесообразным, но может быть чрезмерно избыточным. Может не потребоваться.

Здесь вам не хватает учета контекста, масштаба и бизнес-требований проекта.

Под контекстом и областью я имею в виду - вы создаете что-то для внутреннего использования в бизнесе? Клиент-облицовочный? Используется конечными пользователями? Это на самом деле джазовая версия Notepad или новая RDBMS с нуля? То, что должно быть включено, будет сильно зависеть от проекта, на который вы смотрите.

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

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

Интересно, что я думаю, что пункты 1, 2, 4 и 7 уже должны быть выполнены во время концепции вашего прототипа, за исключением того, что я не думаю, что вы должны тестировать каждый метод в каждом классе. Тестируйте критический код, а не проверяйте, правильно ли ведут себя методы get / set.

В зависимости от цели вашего приложения, где безопасность является большой проблемой, пункт 6 может быть достаточно критичным, чтобы его можно было достичь в прототипе. В зависимости от цели вашего приложения, где производительность является ключевым фактором, пункт 5 может иметь решающее значение ... Вы знаете, что я имею в виду. Мое мнение таково, что пункты 3, 5 и 6 могут быть необходимы в прототипе, если они считаются критическими (точка 8 действительно действительна для производственных приложений)

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

В дополнение к тому, что уже было упомянуто, в производственном проекте вам необходимо следующее (среди прочего):

0-Выберите методологию реализации

1-Завершить и опубликовать основные требования (включая варианты использования и т. Д.)

2-Получите правильную архитектуру

3-Выберите правильные инструменты

4-дизайн базы данных для производительности

5-Создайте свой дизайн класса и дизайн рабочего процесса

6-Определить и реализовать стратегию интеграции баз данных / источников данных / каналов с резервной копией

7-Определить и внедрить требования безопасности

8-Организовать для физической реализации (серверы, подключение, лицензии и т. Д.)

9-Запланируйте требования к хранению и определите показатели производительности

10-Произведите все артефакты и установите в производственной среде

11-Тест

12-Поставить окончательное решение и реализовать обратную связь

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

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

Существует два вида прототипов:

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

• «Макетные» прототипы или «каркасы». Это могут быть эскизы пользовательского интерфейса на бумаге и карандашах или даже интерактивные макеты, выполненные на языке, на котором вы можете быстро собрать все вместе, не задумываясь о том, как они сочетаются друг с другом. Он должен использовать поддельные данные, никакой реальной архитектуры и т. Д. Дело в том, что они дают заинтересованным сторонам представление о том, какой будет система, чтобы вы могли уточнить свои требования, но они НЕ МОГУТ использоваться как часть вашего окончательного решения. ,

Я предпочитаю второй вид. Их выбрасывают, потому что на самом деле нет выбора.

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

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

Все прототипы и демоверсии не созданы равными. Весь код может быть бесполезным или некоторые части могут быть выполнены очень хорошо. Неважно, если это демо, вы должны знать разницу. Вы бы не просто выбросили приложение legacay и начали бы сначала? Забудь, что я спросил.