저에게 바보 교정은 사용자가 시도하더라도 소프트웨어를 깰 수 없다는 것을 의미합니다. 예를 들어, 텍스트 상자에서 값을 읽고 double로 변환 한 경우 기본 소프트웨어가 바보 증거인 경우 사용자가 double이 아닌 값을 입력해도 중단되지 않습니다.

최근에 개발 일정을 작성했으며 그 중 하나가 "Idiot proof UI"라는 이름으로 지정되었습니다. 이 소프트웨어를 제작하는 사람들은 농담으로이 용어에 불쾌감을 주었지만이 용어가 실제로 사람들을 화나게하는 위치를 알 수 있습니다.

이것을 말하는 더 좋은 방법은 무엇입니까?

스케줄 항목으로 "Idiot proof UI"를 포함하는 경우 나중에 소프트웨어에 품질을 추가하려고합니다. 잘 설계된 모든 시스템은 입력을 확인하고 당연히 사용자에게 명확한 지침을 제공합니다. 이는 별도의 항목으로 일정에 배치되는 것이 아닙니다 (그런 다음 불가피한 위기가 발생할 때 제거 될 수 있음).

또는 개별 항목이어야하는 경우 (일부 조직에서 일정에 대해 어떻게 생각하는지 알고 있음) "Idiot proof UI"를 "Input Validation Library"로 변경하고 일정 앞쪽으로 이동해야합니다.

내가 생각했던 사용자 입력 유효성 검사는 전문적인 용어라고 생각했습니다. 내부 문서에 사용되는 경우 바보 교정에 아무런 문제가 없습니다.

강화 는 좋은 단어입니다. 누구든지 물어 보면 소프트웨어에 대한 첫 번째 패스는 일반적으로 이상적인 시나리오를 위해 작성되었으며 스틸 툴과 같이 실제 고객이 일상적으로 사용하도록 소프트웨어를 "강화"해야한다고 말합니다.

견고성 은 이것에 대한 또 다른 좋은 단어입니다. 실제 고객이 겪을 수있는 문제에 대해 코드를 강력하게 만듭니다.

두 단어 모두 시원하고 산업적으로 들리며 사용자 또는 프로그래머를 비난하지 말고 요점을 파악하십시오.

BTW, 여기는 Metrowerks의 오래된 마스코트 Arnold입니다. Mac 프로그래머가 열처리로, 단조품 및 모루 및 작은 썰매 망치로 코드를 강화하고 강화하는 데 사용했습니다.

방어 프로그래밍

내가 배운 것입니다. 우리가 나무에서 우리 자신의 비트를 닦아내야 할 때.

PC가 되려면 "예상"프로그래밍이라고합니다.

내가 배우면서 우리는 그것을 방탄 이라고 불렀습니다 .

내가 읽은 다른 완곡 어의 대부분도 적용됩니다.

"내결함성"시스템 또는 UI는 어떻습니까?

"간단한 교정"은 두 가지로 구성되어야합니다.

• UI를 사용자에게 친숙하고 프로그래머가 기대하는 방식으로 데이터를 입력하도록 유도

• 예기치 않은 데이터 값을 입력하여 인터페이스가 손상 될 수 있는지 판별하기 위해 UI 테스트

두 단계 모두 사용자 경험 전문가가 디자인을 심사하고 제공된 코드를 테스터가 심사하여 개발 데이터에 합리적으로 나타날 수 있습니다 (응용 프로그램에 "정확한"의 의미가있는 경우).

바보 방지에는 단순한 입력 검증 이상의 것이 포함됩니다. 나는 그 정의에 그러한 것을 포함시키지 않을 것입니다.

입력 유효성 검사는 사용자 데이터를 무효화하고 유효성을 검사하여 불법 / 무의미한 값을 제거하는 프로세스입니다. 이는 프로그램 외부에서 들어오는 모든 정보를 사용하여 명백한 것을 제거하고 공격 (예 : sql injection 공격)으로부터 자신을 보호하기 위해 항상 수행해야합니다.

나는 멍청이를 법적인 수단을 통해 실수로 자신에게 큰 피해를 입히지 않도록하는 일련의 논리라고 생각합니다.

예를 들어 rm명령 을 거부하고 rm -rf /변형을 수정하면 유효성 검사 또는 정확성과 관련이 없습니다. 완벽하게 유효한 명령입니다. 불행히도, 이것은 유닉스 / 리눅스의 모든 디스크에서 모든 데이터를 지울 수있는 명령입니다. 이를 교정하는 것은이 명령을 거부 rm -rf --i-really-mean-this /하고 대화식 모드 인 경우 경고 후 사용자가 긍정적 인 응답을하도록 제안 합니다.

시스템을 파괴하는 것은 바보가되어서는 안됩니다. 잠재적 난처함을 유발할 수있는 어떤 것도 후보가 될 수 있습니다 (예 : "텍스트에 첨부 한 첨부 파일없이이 이메일을 보내시겠습니까?"및 "이 이메일을 회사 전체? ")

바보 방지는 QA (최고의 바보가되기 위해 노력)와 개발 (이러한 시나리오를 모두 예측하고 그 주위를 디자인하려고 시도) 간의 협력입니다.

보다 친숙한 동의어에 대해서는 "파괴적인 코드 경로 분석"또는 "중요한 작업에 대한 사용자 피드백 활성화"를 제안 할 수 있습니다. 무엇을 호출하든 설계 프로세스 초기에 가능한 빨리 시작해야합니다.

"위생 검사"는 꽤 자주 작동하는 경향이 있습니다 ...

"UI에 Poka-yokes 추가"라고 부릅니다. http://en.wikipedia.org/wiki/Poka_yoke

"오류 처리"또는 "입력 유효성 검사"는 설명하는 데 사용하는 다른 용어입니다. 방탄은 소프트웨어가 거의 모든 것을 처리 할 수있을 정도로 견고하게 만드는 것이므로 일부 서클에서 사용되는 것을 볼 수있는 또 다른 용어 일 것입니다. 암석은 누군가가 여기에서 사용하기를 원한다고 상상할 수있는 또 다른 속어입니다.

"가장 최악의 시나리오 교정". 개발자라면 누구나 할 수 있다면 할 수 있다는 것을 알고 있기 때문 입니다. 따라서 소프트웨어로 최악의 시나리오 상황을 처리 할 준비가되어 있어야합니다.

보안 수단은 외부 사이버 침입으로부터 사용자를 보호하는 방법 일뿐만 아니라 자신을 막아줍니다. 우리는 불완전한 사용자와 불완전한 세상에 살고 있습니다.

금도금 은 어떤 방식 으로든 (GUI 또는 기타) 최종 사용자 인터페이스 환경을 개선 할 때 사용하는 정중하고 긍정적 인 용어 입니다.

말할 수 있듯이 바보 방지는 설계 또는 워크 플로 개선과 함께 해당 프로세스의 가장 큰 부분입니다 (최종 사용자 피드백 승인 고려).

여기서 아이디어는 작업 환경에서 해당 용어를 자유롭게 사용할 수 있으며 시간이 걸릴 수 있지만 일반적으로 약간의 비용이 들더라도 관리 및 사용자 모두에게 중요한 프로세스 (한 번 완료)로 간주 될 수 있다는 것입니다.

이 프로세스 (종종주기 종료) 프로세스와 관련된 다른 많은 용어는 다음과 같이 들립니다.

• 사용자 (보통 관리 ;-)가 바보임을 암시합니다.
• 달성하기 어렵다
• 순 가치가 거의 없다

금을 프로세스 (일반적으로 "비용"이 아닌 "가치"와 동일 함)와 연관시킴으로써 프로세스가 일부 관리자의 사고 방식에서 비용에서 투자로 바뀌는 것을 볼 수있었습니다.

이 일이 끝날 때까지 그 강철 조각은 아직 보석이 아니라고 공개적으로 말하고 있습니다. 그러나 일단 도금되면 ... 그 가치가 있습니다.

제조 공정과 관련하여 가장 많이 사용하지만 Poka-Yoke 는 정말 적합하다고 생각합니다 .

"[poka yo-ke]는"실패 "또는"실수 방지 "를 의미하는 일본어 용어입니다.

원래는 바카 요케 (baka-yoke)로 설명되었지만 이것이 "방어"(또는 "멍청이 방지")를 의미하므로 이름이 더 온화한 포카 요크로 변경되었습니다.

더 광범위하게,이 용어는 사용자가 부정확하게 작동하는 것을 방지하기 위해 제품에 설계된 모든 행동 형성 제약 조건을 의미 할 수 있습니다. "

더 큰 상점에서 흔히 사용되는 용어는 품질 보증 (QA) 입니다.

릴리스주기 내에서 고유 한 특정 의미로 성형 할 수있는 일반적이고 모호한 용어입니다.

우리는 그것을 인간 교정이라고 부릅니다. 우리는 모두 바보입니다.