Определите «готовый к производству»

Мне было любопытно об этом некоторое время. Что именно означает «готовый к производству» или его варианты? Совсем недавно я искал информацию о sqlite и нашел эту ветку , где многие полагают, что sqlite не готов к производству.

Я знаю разницу между разработкой / тестированием и производством; Мое определение производства - это все, что предоставляется клиенту или будет использоваться не программистами.

Тем не менее, кажется, что есть много предметов, которые не определены как готовые к производству. Но в действительности они могут идеально подходить, и люди просто имеют предубеждение против них, например, sqlite, python, продукты не-MS и т. Д.

Малый офис против предприятия? Один пользователь против многопользовательского? Клиент против сервера? Где вы проводите черту?

Зависит от того, кто вы есть.

Определение программиста "готов к производству":

• это работает
• соответствует требованиям проекта
• его дизайн был хорошо продуман
• это стабильно
• это ремонтопригодно
• это масштабируемо
• это задокументировано

Определение руководства «готовый к производству»:

• это работает
• это принесет прибыль

Извините, что перефразировал этот старый вопрос, но я натолкнулся на него и не смог устоять.

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

Есть много определений, которые можно использовать для «производства готово».

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

Нижеприведенные определения предполагают, что «производство» имеет контекст «некоторый серьезный результат зависит от успешного запуска продукта».

• Другими словами, программное обеспечение, на котором работает ваш бесплатный форум «Лучшие орхидеи для роста в Неваде», приносящее вам 3 доллара в месяц в доходах AdSense, выходит за рамки контекста «производства», в то время как прошивка Space Shuttle твердо в этом контексте.

• Все остальное в масштабе, с некоторыми вещами немного серыми (например, какое-то программное обеспечение проводит академические исследования - с одной стороны, нет очевидного влияния на производство, если оно ломается в общей ситуации; с другой стороны, политические решения на триллион долларов делается правительствами на основе некоторых конкретных исследований).

2 определения, которые я могу придумать сейчас:

1. Может использоваться для целей, которые, когда вещи ломаются, подразумевают материальные потери, согласно стандартному анализу риска.

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

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

   Следовательно, печально известная оговорка Java «не для использования на атомных электростанциях».

2. Разумно ожидать, что ваши коллеги прошли Due Diligence.

   Например, если в случае судебного разбирательства группу из N случайных экспертов из данной области спросят «учитывая эти детали, было ли это производство готово?», Вы достаточно уверены, что большинство таких экспертов согласятся с вами, что это было готовы, основываясь на следственных и рабочих усилиях, которые вы могли разумно предпринять в данных обстоятельствах. Если вам не удалось написать более 10% тестовых случаев, вы провалили Due Diligence. Если ваша программа потерпела неудачу из-за ранее неизвестной ошибки в компиляторе gcc, вы, вероятно, не потерпите неудачу, если ваше программное обеспечение не запускало что-то жизненно важное, что требовало уровня проверки, необходимого для обнаружения даже этой ошибки.

SQLite нельзя использовать для производственных баз данных, поскольку он явно разработан без многих функций, которые считаются «необходимыми». Например, блокировки влияют на всю базу данных, внешних ключей нет, и до SQLite3 не было даже типов данных.

В более общем смысле это означает, что система, которая отлично работает для очень небольшого числа пользователей (1-5) в процессе разработки, будет аварийно завершать работу и гореть при воздействии более высоких нагрузок.

Я должен отметить, что это также зависит от среды, в которой используется приложение. Возвращаясь к примеру с SQLite, он идеально подходит для производственного использования, если есть только один клиент. Mac OS X широко использует SQLite в среде CoreData - я считаю, что он обрабатывает такие вещи, как музыкальная база данных iTunes пользователя и почтовый ящик iMail. Только не пытайтесь использовать его как настоящую клиент-серверную базу данных.

Как вы предлагаете в последней части вопроса, «Готовность к производству» не обязательно является определением размера развертываний, а скорее подходит для предполагаемого использования и требований. Например, для однопользовательского клиентского приложения SQLite может быть готов к работе. Предполагаемый рынок чаще всего определяет, готово ли приложение или система к использованию приложения или системы.

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

• Нет проблем с серьезностью 1; а также,
• Нет проблем с уровнем серьезности 2, которые не помечены как «Известная отправка»

Решение KS принято мной и еще одним человеком.

Что ж, мое мнение о производстве готово, оно было подписано руководством. Он работает, отвечает требованиям или его масштабируемость и т. Д. Уже выполнены, прежде чем мы даже сможем произнести слово p. Подписание - это взаимно согласованная точка выхода с точки зрения управления. Ps. Я не буду считать что-либо готовое к производству, если sev 4 bug остаётся открытым.