Насколько избыточность / надежность должна реализовывать сложное программное обеспечение?

Основное внимание в этом вопросе: Некоторые программы выполняют «дополнительную работу», чтобы увеличить вероятность «в конечном итоге успешного / удовлетворительного» результата, несмотря на одну или несколько внутренних ошибок в программном обеспечении, что требует более длительного времени выполнения при возникновении этих ошибок. Все это происходит без ведома пользователя, если результат был успешным.

Определение сложного программного обеспечения:

• Содержит код, написанный (предоставленный) более чем 10 разработчиками в течение срока его службы и не написанный в тот же период времени
• Зависит от более чем 10 внешних библиотек, каждая с оговорками
• Типичная программная задача (для получения результата, требуемого пользователем) требует 10 или более входных параметров, где большинство из них имеют значения по умолчанию, но их можно настроить, если пользователю требуется контроль.
• Самое главное, программное обеспечение, которое имеет соответствующую сложность относительно выполняемой задачи, то есть не является чрезмерно сложным .

Отредактировано: что сложного? Пожалуйста, см. Есть большая разница между сложным и сложным . (Прямая ссылка)

Определение избыточности / робастности в этом вопросе :
(добавлена ​​робастность на основе комментариев)

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

Пример такого программного обеспечения:

• Миграция базы данных
  • Бизнес база данных
  • База данных контроля источника и т. Д.
• Пакетное преобразование между документом Word и документом OpenOffice, PowerPoint и OpenOffice Draw и т. Д.
• Автоматический перевод всего сайта
• Автоматический анализ программного пакета, такого как Doxygen, но там, где анализ должен быть более надежным (т.е. не просто инструмент документирования)
• Сетевая связь, где пакеты могут быть потеряны и ожидается несколько попыток

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

Возможно связано:

• Как работать со сложными кодами в (огромных) проектах
• Как людям удается писать и поддерживать чрезвычайно сложный и трудный для чтения код?

Это деловой вопрос, а не технический.

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

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

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

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

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

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

Изменить: в свете перефразирования вопроса я добавлю немного о надежности. На мой взгляд, проверка параметров должна выполняться только в том случае, если A) вы принимаете очень специфический формат, такой как значение даты в виде строки или B), различные параметры потенциально могут конфликтовать друг с другом или являются взаимоисключающими.

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

Что касается B), взаимоисключающие параметры представляют плохую структуру. Должно быть два класса, один, который обрабатывает один случай, а другой, который обрабатывает его по-другому. Все обычные операции могут выполняться в одном базовом классе, чтобы избежать избыточности.

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

Программное обеспечение должно прощать ошибки пользователя и полностью нетерпимо к ошибкам программиста.

Это означает, что программное обеспечение должно быть очень надежным и обеспечивать плавное восстановление для таких вещей, как ошибки ввода пользователя и ошибки конфигурации системы. По крайней мере, дружеское сообщение об ошибке, в котором указано, где произошла ошибка (поле ввода, файл конфигурации, аргумент командной строки и т. Д.) И какое ограничение было нарушено («должно быть меньше X символов»), допустимыми параметрами являются [X , Y, Z] "и т. Д.). Для дополнительной надежности программное обеспечение может предложить альтернативу или использовать разумное значение по умолчанию (но оно всегда должно указывать, что оно не использует именно то, что указано пользователем).

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

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

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

Это просто дополнительная ненужная сложность. Вы не должны тратить время на выяснение того, как одна функция должна обрабатывать ошибку, вызванную неправильным использованием другой. Если вы говорите о «надежности» - вам это не нужно. Замените его утверждениями и тщательным интеграционным тестированием.

Это вещь требований.

Есть ли требование к надежности?

«При сбое канала связи ошибочные пакеты отбрасываются» «Когда канал возобновляет работу, ни одна транзакция не обрабатывается дважды»

должны быть случаи использования для восстановления после ошибок (иначе как вы узнаете, как это произойдет?)

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

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

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