Яка різниця між прототипом і рішенням рівня виробництва?

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

У минулому я створив багато демо-рішень. Мені зараз призначено архітектора та впровадити веб-рішення на рівні виробництва, тому я хотів запитати - на дуже високому рівні, що потрібно для перетворення демонстрації у рішення на рівні виробництва. Наскільки я розумію, це вимагатиме (крім функціонального виконання вимог клієнтів):

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's, тому що я маю на увазі, що я вважаю прототип основою / оболонкою / скелетом ваших майбутніх розробок, тому для мене прототип не слід викидати.

Крім того, що вже було сказано, у виробничому проекті вам потрібно (серед інших):

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

1-Доопрацювати та опублікувати основні вимоги (включаючи випадки використання тощо)

2 - Отримайте правильну архітектуру

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

4-Дизайн бази даних для продуктивності

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

6-Визначте та застосуйте стратегію інтеграції резервних баз даних / джерел даних / каналів

7-Визначте та реалізуйте вимоги безпеки

8-домовленість для фізичної реалізації (сервери, підключення, ліцензії тощо)

9-План вимог щодо зберігання та визначення заходів щодо виконання

10 - Виготовте всі артефакти та встановіть у виробничих умовах

11-Тест

12 - Надайте остаточне рішення та впроваджуйте зворотній зв'язок

Найважливішою особливістю якісних рішень для виробництва є - на мою думку - надійність .

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

Існує два види прототипів:

• Швидке і брудне "доказ поняття" додатків, які "очищаються" і стають виробничим кодом. Етап "прибирання", як правило, або є кошмаром, або це дійсно "зачистка проблем під килимом", що призводить до величезної технічної заборгованості.

• "Макети" прототипів або "каркасних". Це можуть бути ескізи інтерфейсу з папером і олівцем, або навіть інтерактивні макети, зроблені мовою, де ви можете швидко зібрати такі речі разом, не маючи великої думки про те, як це поєднується. Він повинен використовувати підроблені дані, відсутність реальної архітектури тощо. Справа в тому, що вони дають зацікавленим сторонам уявлення про те, якою буде система, щоб ви могли уточнити свої вимоги, але вони НЕ МОЖНА використовуватись як частина вашого остаточного рішення .

Я віддаю перевагу другому виду. Їх викидають, бо насправді вибору немає.

Я кажу, будуйте його як проект без демо-версії, але тепер ви можете включити те, що ви дізналися з демонстрації, у свій дизайн. Початкове кодування може бути поганим навіть після початку виробництва. Більшу частину цього вам доведеться переробляти.

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

Всі прототипи та демонстрації не створюються рівними. Весь код може бути нікчемним, або певні частини були зроблені дуже добре. Не має значення, чи це демо, ви повинні знати різницю. Ви б не просто викинули додаток legacay і почали би так, чи не так? Забудь, я запитав.