Dla mnie Idiot Proofing oznacza po prostu upewnienie się, że użytkownik nie może złamać oprogramowania, nawet jeśli spróbuje. Na przykład, jeśli wartość jest odczytywana z pola tekstowego i jest konwertowana na wartość podwójną, jeśli oprogramowanie leżące u podstaw jest odporne na idiotyzm, nie złamie się, jeśli użytkownik wpisze wartość inną niż podwójna.

Niedawno napisałem harmonogram rozwoju, a jeden z elementów nazwano „Idiot proof UI”. Ludzie, z którymi buduję to oprogramowanie, żartobliwie udają obrazę tego terminu, ale widzę, gdzie ten termin naprawdę by go zdenerwował.

Jak można to lepiej powiedzieć?

Jeśli dołączasz „Idiot proof UI” jako element harmonogramu, próbujesz po prostu dodać jakość do swojego oprogramowania. Każdy dobrze zaprojektowany system zweryfikuje swoje dane wejściowe i da użytkownikom jasne wskazówki, nie jest to coś, co zostanie umieszczone w harmonogramie jako dyskretny element (który następnie zostanie usunięty, gdy nadejdzie nieunikniony kryzys).

Alternatywnie, jeśli musi to być dyskretny element (wiem, jak niektóre organizacje myślą o planowaniu), „Idiot proof UI” należy zmienić na „Input Validation Library” i przenieść na początek harmonogramu.

Sprawdzanie poprawności danych wprowadzanych przez użytkowników uważam za termin profesjonalny. Nie widzę jednak nic złego w dowodach idiotyzmu, jeśli są używane w dokumentach wewnętrznych.

Hartowanie to dobre słowo. Jeśli ktoś zapyta, powiedz mu, że pierwsze przekazanie oprogramowania jest zwykle napisane dla idealnych scenariuszy, i podobnie jak narzędzia stalowe, oprogramowanie musi zostać „utwardzone” w celu zgrubnego codziennego użytkowania przez prawdziwych klientów.

Robustification jest kolejnym dobrym słowem na ten temat - czynisz kod odpornym na wyzwania, jakie stawiają przed nim prawdziwi klienci.

Oba słowa brzmią fajnie i industrialnie, nie obwiniaj użytkowników ani programistów, i przejdź do sedna sprawy.

BTW, oto stara maskotka Metrowerksa, Arnold, facet, który pomagał nam programiści komputerów Mac hartować i udoskonalać nasz kod za pomocą pieca do obróbki cieplnej, kuźni oraz kowadła i małego młota kowalskiego:

Programowanie obronne

Tego mnie nauczono. Kiedy musieliśmy wyrywać nasze własne kawałki z drewna.

Jeśli chcesz być na PC, nazwij to programowaniem „antycypacyjnym”.

Kiedy się uczyłem, nazwaliśmy to kuloodpornym .

Dotyczy to jednak większości innych eufemizmów, które czytałem.

Co powiesz na system „tolerujący błędy” lub interfejs użytkownika?

„Idiot proofing” powinien składać się z obu tych elementów

• zaprojektowanie interfejsu użytkownika w taki sposób, aby był przyjazny dla użytkownika i prowadził użytkownika do wprowadzania danych zgodnie z oczekiwaniami programistów, oraz

• testowanie interfejsu użytkownika w celu ustalenia, czy interfejs może zostać uszkodzony, wprowadzając nieoczekiwane wartości danych.

Oba kroki mogą w uzasadniony sposób pojawić się w harmonogramie programowania, w którym projekt jest sprawdzany przez eksperta ds. Doświadczenia użytkownika, a dostarczony kod jest weryfikowany przez testera, aby upewnić się, że nieprawidłowe dane są obsługiwane poprawnie (dla tego, co „poprawnie” oznacza dla aplikacji).

Zabezpieczanie przed idiotami wymaga znacznie więcej niż prostej weryfikacji danych wejściowych. Nie zawarłbym nawet takiej rzeczy w jej definicji.

Sprawdzanie poprawności danych wejściowych jest procesem polegającym na odkażaniu i sprawdzaniu poprawności danych użytkownika w celu wyeliminowania niedozwolonych / bezsensownych wartości. Powinno to zawsze odbywać się z wszelkimi informacjami pochodzącymi spoza twojego programu, aby wyeliminować oczywiste, a także chronić się przed atakami (np. Ataki typu sql injection).

Uważam, że ochrona przed idiotami jest zbiorem logiki, która zapobiega przypadkowemu wyrządzeniu użytkownikowi poważnych szkód za pomocą środków prawnych.

Na przykład wykonanie rmpolecenia odrzucenia rm -rf /i zamknięcia wariantów nie ma nic wspólnego z sprawdzaniem poprawności lub poprawnością. To doskonale poprawne polecenie. Niestety jest to polecenie, które może i może usunąć wszystkie dane ze wszystkich dysków w systemie Unix / Linux. Dowodzenie przez idioty to odrzuciłoby to polecenie i sugerowałoby rm -rf --i-really-mean-this /, lub w trybie interaktywnym, aby użytkownik napisał odpowiedź twierdzącą po ostrzeżeniu.

Wszystko, co jest destrukcyjne dla systemu, powinno być zabezpieczone przed idiotami. Wszystko, co może powodować potencjalne zażenowanie, może być również kandydatem (np. „Czy na pewno chcesz wysłać tę wiadomość e-mail bez załącznika, nawet jeśli wspomniałeś o niej w tekście?” Oraz „czy na pewno chcesz wysłać tę wiadomość e-mail na adres cała firma? ”)

Zabezpieczanie przed idiotami to współpraca między QA (starając się być najlepszym idiotą) a Programistą (starając się przewidzieć wszystkie te scenariusze i zaprojektować je wokół).

Jeśli chodzi o bardziej przyjazny synonim, czy mogę zasugerować „destrukcyjną analizę ścieżki kodu” lub „włączyć informacje zwrotne od użytkowników dotyczące operacji krytycznych”. Jakkolwiek to nazwiesz, naprawdę powinieneś rozpocząć go jak najwcześniej na etapie projektowania.

„Sprawdzanie rozsądku” dość często działa dość dobrze…

Nazwij to „dodaniem jarzm Poka do interfejsu użytkownika”. http://en.wikipedia.org/wiki/Poka_yoke

„Obsługa błędów” lub „sprawdzanie poprawności danych wejściowych” byłyby innymi terminami, których użyłbym do tego, co opisujesz. Kuloodporny byłby inny termin, który mogłem zobaczyć w niektórych kręgach, ponieważ chodzi tu o to, aby oprogramowanie było wystarczająco solidne, aby obsłużyć prawie wszystko. Rock solid byłby kolejnym slangowym wyrażeniem, które mogłem sobie wyobrazić, że ktoś też chciałby tutaj użyć.

„Korekta najgorszego scenariusza”. Ponieważ jako programiści wszyscy wiemy, że jeśli da się to zrobić, to będzie zrobione . Musisz więc być przygotowany na poradzenie sobie z najgorszym przypadkiem ze swoim oprogramowaniem.

Środki bezpieczeństwa to nie tylko sposób ochrony użytkowników przed inwazjami cybernetycznymi, ale także przed sobą. Żyjemy w niedoskonałym świecie z niedoskonałymi użytkownikami.

Pozłacanie to grzeczny (i bardzo pozytywnie brzmiący) termin, którego używam, mówiąc o poprawianiu interfejsu użytkownika w jakikolwiek sposób (GUI lub inny).

Jak twierdzisz, ochrona przed idiotami jest największą częścią tego procesu, wraz z ulepszeniami projektu lub przepływu pracy (pomyśl o potwierdzeniu opinii użytkowników końcowych).

Chodzi o to, że możesz swobodnie używać tego terminu w środowisku pracy i jest postrzegany jako cenny proces (po zakończeniu) zarówno przez kierownictwo, jak i użytkowników, nawet jeśli może to zająć trochę czasu (a zatem generalnie kosztuje trochę pieniędzy).

wiele innych terminów związanych z tym procesem (często na koniec cyklu) sprawia, że ​​brzmi to tak:

• sugeruje, że użytkownicy (często zarządzanie ;-) są głupi
• jest trudny do osiągnięcia
• ma niewielką wartość netto

Kojarząc złoto z procesem (metal zwykle utożsamiany z „wartością”, a nie „kosztem”), zauważyłem, że proces zmienił się z wydatków na inwestowanie w sposób myślenia niektórych menedżerów.

To jak otwarcie stwierdzenie, że dopóki to się nie stanie, ten niezgrabny kawałek stali nie jest jeszcze biżuterią. Ale kiedy zostanie pokryty ... to będzie cenny.

Najczęściej używa się w odniesieniu do procesów produkcyjnych, ale myślę, że naprawdę dobrym dopasowaniem jest Poka-Yoke :

„[poka yo-ke] to japoński termin oznaczający„ zabezpieczenie przed awarią ”lub„ zabezpieczenie przed błędami ”

Pierwotnie był opisywany jako baka-jarzmo, ale ponieważ oznacza to „głupotę” (lub „głupotę”), nazwa została zmieniona na łagodniejsze poka-jarzmo.

Mówiąc szerzej, termin ten może odnosić się do wszelkich ograniczeń kształtujących zachowanie zaprojektowanych w produkcie, aby zapobiec nieprawidłowej obsłudze przez użytkownika. ”

Częstym terminem w większych sklepach jest także Quality Assurance (QA) .

Jest to ogólny, niejasny cel, który możesz nadać swojemu indywidualnemu znaczeniu w cyklu wydawniczym.

Nazywamy to sprawdzianem człowieka. Wszyscy jesteśmy idiotami.