Написання надійного коду проти перенапруження

Звідки ви знаєте, що ви пишете найбільш надійний код без можливого перенапруження?

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

Звідки ви знаєте, що ви пишете найбільш надійний код без можливого перенапруження?

Що ви вважаєте надійним кодом? Кодекс, який уже є майбутнім доказом і настільки потужний, що може вирішити будь-яку ситуацію? Неправильно, ніхто не може передбачити майбутнє! І знову неправильно, бо це буде складний, незрозумілий безлад.

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

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

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

Надійний код - це завжди завжди простий і чистий код, але простота - це ознака, яку не завжди легко досягти. Тим не менш, ви повинні прагнути до цього. Завжди просто записуйте найпростіший можливий код і додайте складності лише тоді, коли у вас немає іншого вибору.

Простота є міцною, складність - крихкою.

Складність вбиває.

Я намагаюся тримати рівновагу, орієнтуючись на

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

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

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

З іншого боку, власна інженерія може впасти у сферу повної реалізації функцій, які не були потрібні або просили (деякі функції, які клієнт робить НЕОБХІДНІ, але його ніколи не вимагали!) Або це можна визначити, отримавши надмірно складний дизайн або надмірно складний код для вирішення відносно простої проблеми.

1) Отримати вимоги.

2) Напишіть мінімальний код, щоб відповідати вимогам. Якщо щось неоднозначне, зробіть освічену здогадку. Якщо це супер неоднозначне, повернутися до 1.

3) Надіслати на тестування.

4) Якщо випробувачі кажуть, що це добре, задокументуйте затвердження. Якщо щось вимкнено, поверніться до 1.

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

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

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

Існує сильна тенденція намагатися жорстко управляти надмірністю за допомогою повідомлень. Їх не тільки важко переконатись у правильності, але й може призвести до величезної неефективності. (Частина спокуси писати сповіщення виникає, оскільки в ООП вони практично заохочуються.)

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

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

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

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

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

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

Міцність: ступінь, в якій система продовжує функціонувати за наявності недійсних входів або стресових екологічних умов. (Код завершено 2, с.464)

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

Принцип YAGNI стосується додавання функцій, які можуть знадобитися програмі. Але цей принцип не застосовується до надійності. Програмісти, як правило, завищують ймовірність того, що дане майбутнє розширення знадобиться (особливо, якщо це круте), але вони недооцінюють ймовірність того, що щось піде не так. Крім того, якщо виявиться, що після цього потрібна пропущена функція, програміст може записати її пізніше. Якщо виявиться, що потрібно пропустити перевірку помилок, можливо, шкода може бути зроблена.

Тому насправді краще помилитися з боку проведення перевірок на наявність незвичних умов помилок. Але є баланс. Деякі речі, які слід врахувати в цьому балансі:

• Як часто може виникнути ця помилка?
• Яка вартість виникнення цієї помилки?
• Це для внутрішнього чи зовнішнього використання?

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

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