Скільки надмірності / надійності має впроваджувати складне програмне забезпечення?

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

Визначення складного програмного забезпечення:

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

Редаговано: Що є складним? Будь ласка, подивіться. Існує велика різниця між складними та складними . (пряме посилання)

Визначення надмірності / стійкості в цьому питанні :
(Додано надійність на основі коментарів)

• Якщо програмне завдання не вдалося, коли використовувався поточний набір параметрів, спробуйте інші параметри.
  • Очевидно, слід знати, що ті "різні" параметри використовують інший шлях коду, можливо, це призведе до іншого (сподіваємось, кращого) результату.
  • Іноді ці різні кодові шляхи вибираються на основі спостережень зовнішніх бібліотек.
• Врешті-решт, якщо реально виконане завдання дещо відрізняється від специфікації користувача, користувач отримає звіт із деталізацією розбіжності.
• Нарешті, як і 10-плюс настроювані параметри, надмірність та звітність також можна налаштувати.

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

• Міграція баз даних
  • Бізнес бази даних
  • База даних управління джерелами тощо.
• Пакетне перетворення між документом Word та документом OpenOffice, PowerPoint та OpenOffice Draw тощо.
• Автоматичний переклад цілого веб-сайту
• Автоматичний аналіз програмного пакету, такого як Doxygen, але там, де аналіз повинен бути більш надійним (тобто не лише інструментом документації)
• Мережевий зв’язок, де пакети можуть бути втрачені та очікується кількість повторних спроб

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

Можливо, пов'язані:

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

Це питання бізнесу, а не технічне.

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

Але якщо користувачам вашої системи потрібна надійна система, ви повинні будувати її таким чином. І вам слід зробити це надійним саме таким чином, щоб вам і їм потрібно було досягти максимального довгострокового успіху, ігноруючи види надмірності / надійності, які їм не потрібні.

Як правило, я починаю грубо, а потім додаю стійкості з часом. Я часто ставлю такі питання, як ця частина звичайного процесу планування. Я, як правило, працюю в стилі екстремального програмування, де ми складаємо довгий список бажаних функцій, і я вкладаю також функції надійності. Наприклад, "Система переживає невдачу жодного вікна", змішується з речами на кшталт "Користувач може приєднатися за допомогою облікових даних Facebook". Що б хто не з’явився першим, я будую першим.

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

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

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

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

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

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

У ситуаціях, коли кількість параметрів методу стає 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....

Це лише додаткова непотрібна складність. Не слід витрачати таймінги на з'ясування того, як одна функція повинна обробляти помилку, введену через неправильне використання іншої. Якщо це тип «надійності», на який ви посилаєтесь - він вам не потрібен. Замініть його на твердження та ретельне тестування інтеграції.

Це вимога річ.

Чи є вимога до надійності?

"Коли зв'язок не працює, помилкові пакети відкидаються" "Коли посилання відновиться в роботі, жодна транзакція не обробляється двічі"

повинні бути випадки використання для відновлення помилок (інакше як ви знаєте, як це станеться?)

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

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

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