Бути ліберальним у тому, що ти приймаєш… чи ні?

[Відмова від відповідальності: це питання є суб'єктивним, але я вважаю за краще отримати відповіді, підкріплені фактами та / або рефлексіями]

Я думаю, що всі знають про Принцип стійкості , зазвичай підсумований Законом Постела:

Будьте консервативними в тому, що ви надсилаєте; будьте ліберальні в тому, що приймаєте.

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

Я помічаю, хоча там RFC протоколу TCP вважає "мовчазною відмову" прийнятною, якщо не вказано інше ... що, по крайней мере, є цікавою поведінкою.

Є й інші приклади застосування цього принципу у всій торгівлі програмним забезпеченням, які регулярно спливають, оскільки вони кусали розробників, зверху в мене:

• Вставка ядра в напів двокрапку
• C (мовчазний) вбудований перехід (що було б не так вже й погано, якби він не врізався ...)

і є інструменти, які допоможуть реалізувати "розумну" поведінку:

• фонетичні алгоритми, що відповідають іменам ( Double Metaphone )
• алгоритми дистанції рядків ( відстань Левенштейна )

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

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

І саме це спричинило мене до наступного питання:

Створюючи інтерфейс (бібліотека, клас, повідомлення), ви схиляєтесь до принципу надійності чи ні?

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

Я б сказав твердість, коли це не вносить двозначності .

Наприклад: Під час аналізу списку, розділеного комою, чи немає пробілу до / після коми, не змінюється смислове значення.

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

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

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

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

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

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

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

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

На жаль, так званий "принцип стійкості" не призводить до надійності. Візьмемо як приклад HTML. Багато клопоту, сліз, марнування часу та енергії можна було б уникнути, якби браузери з самого початку суворо розбирали HTML, а не намагалися вгадати значення неправильного вмісту.

Переглядач повинен був просто відображати повідомлення про помилку, а не намагатися виправити його під обкладинками. Це змусило б усіх негідників виправити безлад.

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

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

Вихід завжди повинен бути суворим.

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

Ми знали ще з 50-х років, як правильно перевірити код. Запустіть його через суворий аналізатор, і якщо щось не синтаксично правильно, киньте помилку і перервіть. Не проходьте, не збирайте 200 доларів, і за любов до всього, що є бінарним , не дозволяйте якійсь комп'ютерній програмі намагатися прочитати розум кодера, якщо він помилився!

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

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

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

У файлі "Jargon" також є історія жахів про "вгадування" наміру користувача.

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

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

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

ІМО, надійність - одна зі сторін дизайнерських компромісів, а не принцип "переваги". Як багато хто зазначав, нічого не смердить, як дути чотири години, намагаючись розібратися, де ваш JS пішов не так, тільки щоб виявити справжню проблему - лише один браузер зробив належну справу з XHTML Strict. Це дозволило розібратися на сторінку, коли якась частина поданого HTML була повною катастрофою.

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

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

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

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

Спроба надати функціонал 2010 року у веб-переглядачі 1999 року, коли ви могли просто поставити нижчу технічну сторінку, є ще одним прикладом нерозумної компромісної дизайну. Можливості, які я бачив, витрачали витрачені на час розробника, витрачені на оброблені помилками способи просто для отримання закруглених кутів на елементі, що нависає над градієнтним фоном! А для чого? Поставити сторінки з вищими технологіями, які погано працюють із перевіреними технофобами, обмежуючи при цьому вибір на веб-переглядачах вищого рівня.

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

Ніколи не мовчи мовчки . Крім того, спроба вгадати, чого хоче користувач API / бібліотеки, не здається поганою ідеєю. Я б не пішов за цим; маючи сувору вимогу, може виявити помилки в коді виклику та / або неправильно тлумачити ваш API / бібліотеку.

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

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

У будь-якому випадку, що не 100% очевидно і детерміновано, що один вхід повинен бути перетворений на інший, не слід робити перетворення з ряду вже згаданих причин (порушення сумісності при рефакторингу, найменше здивування користувачів).

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

Я б порекомендував вам прочитати це моє питання про подібний випадок.