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

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

Який приємний спосіб сказати це?

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

Крім того, якщо це має бути дискретний пункт (я знаю, як деякі організації думають про планування), "Ідентифікаційний інтерфейс, що підтверджує ідіотизм", слід змінити на "Бібліотека перевірки вхідних даних" і перемістити на передній план.

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

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

Ростифікація - це ще одне хороше слово для цього - ви робите код надійним у вирішенні завдань, які реальні клієнти вирішуватимуть.

Обидва слова звучать круто і по-промисловому, не звинувачуйте користувачів або програмістів, і не переймайтеся.

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

Оборонне програмування

Це те, чого мене вчили. Ще тоді, коли нам довелося вибивати наші шматочки з дерева.

Якщо ви хочете бути ПК, називайте це "передчуттям" програмування.

Коли я вчився, ми називали це куленепробиванням .

Хоча більшість інших евфемізмів, яких я читав, також застосовуються.

Як щодо системи "Відмовостійкість" чи інтерфейсу користувача?

"Ідіотське підтвердження" має складатися з обох

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

• тестування інтерфейсу користувача, щоб визначити, чи можна порушити інтерфейс, ввівши несподівані значення даних.

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

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

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

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

Наприклад, примусово rmвідхилити команду rm -rf /та закрити варіанти не має нічого спільного з валідацією чи правильністю. Це цілком дійсна команда. На жаль, це команда, яка могла і може видалити всі ваші дані з усіх ваших дисків в Unix / Linux. Ідіот, що підтверджує це, відхилив би цю команду і запропонував rm -rf --i-really-mean-this /, або якщо він буде в інтерактивному режимі, користувач вводить позитивний відповідь після попередження.

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

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

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

"Перевірка обгрунтованості" працює досить добре досить часто ...

Назвіть це "додавання Poka-yokes до інтерфейсу користувача". http://en.wikipedia.org/wiki/Poka_yoke

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

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

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

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

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

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

багато інших термінів, пов'язаних із цим процесом (часто в кінці циклу), звучать таким чином:

• Має на увазі користувачів (часто управління ;-) - німі
• важко досягти
• має чисту вартість

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

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

Найчастіше використовують у відношенні виробничих процесів, але я думаю, що справді добре підійде Poka-Yoke :

"[пока йо-ке] - японський термін, що означає" невдача "або" захист від помилок "

Спочатку його називали бака-ярмом, але оскільки це означає "дурень" (або "ідіот-захист"), ім'я було змінено на більш м'яке пока-ярмо.

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

Поширеним терміном у більших магазинах є також забезпечення якості (QA) .

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

Ми називаємо це людським доведенням. Всі ми ідіоти.