우리는 얼마나 방어 적이어야합니까?

우리는 몇 가지 코드를 통해 Pex 를 실행 해 왔으며 좋은 것들을 보여주었습니다.

그러나 Pex의 좋은 점 중 하나는 반드시 문제를 찾으려고 노력하는 것을 멈추지 않는다는 것입니다.

우리가 발견 한 영역은 문자열을 전달할 때 빈 문자열을 확인하지 않았다는 것입니다.

그래서 우리는 변경했습니다 :

if (inputString == null)

에

if (string.IsNullOrEmpty(inputString)) // ***

초기 문제가 해결되었습니다. 그러나 Pex를 다시 실행했을 때 다음과 같이 결정했습니다.

inputString = "\0";

문제를 일으켰습니다. 그리고

inputString = "\u0001";

우리가 결정한 것은 우리가 만나면 기본값을 사용할 수 있고 // ***다른 이상한 입력으로 인한 예외를보고 행복하게 처리한다는 것입니다.

충분합니까?

코딩에 얼마나 방어적인지를 결정하는 데 도움이되는 세 가지 질문이 있습니다.

첫째-입력이 잘못되면 어떤 결과가 발생합니까? 개발자의 PC 중 하나에 오류 메시지가 표시되면 방어적인 것이 중요하지 않을 수 있습니다. IE 회계 정보 중단으로 인해 고객에게 재정적 인 문제가 발생할 수 있습니까? 생명이 위험에 처한 실시간 시스템입니까? 수명 / 사망 시나리오에서는 실제 기능 코드보다 더 많은 유효성 검사 및 오류 처리 코드가 있어야합니다.

둘째, 얼마나 많은 사람들이이 기능이나 코드를 재사용합니까? 너 뿐이야? 부서? 너의 회사? 당신의 고객? 코드를 많이 사용할수록 방어 성이 높아집니다.

셋째-유효성을 검사하는 입력 소스는 무엇입니까? 사용자 또는 공개 웹 사이트에서 입력하면 매우 방어 적입니다. 입력이 항상 코드에서 오는 경우 다소 방어 적이지만 점검에 과도한 시간을 소비하지 마십시오.

시스템에서 더 많은 오류 검사 및 유효성 검사를 추가 할 수 있습니다. 요점은이 코드를 작성하고 유지 관리하는 비용이 코드 오류로 인해 발생하는 문제의 비용보다 중요하다는 것입니다.

사용자는 악의적이며 자신이 입력 한 내용은 최대한 엄격하게 확인해야합니다.

사용자 입력없이 또는 위생 처리 된 데이터로부터 생성 된 모든 것을 동일한 수준에서 점검 할 필요는 없습니다. 여기서 문제는 코드가 강화되지 않았다는 사실을 잊었 기 때문에 나쁜 데이터에서 이러한 방법을 잊어 버렸을 때입니다.

항상 확인해야 할 것은 오버플로 또는 충돌을 일으킬 수있는 것입니다. 그 방법이 얼마나 깊이 묻혀 있는지, 그리고 그 상태가 결코 일어날 수 없다는 것이 얼마나 중요하지는 않습니다. 어쨌든 머피를 퇴치하기 위해 프로그래밍해야합니다.

나는 당신이 필요로하는만큼 방어적일 것입니다. 조금 애매하지만, 나는 추측하지만 설명하려고합니다.

메소드를 올바르게 수행 할 때 해당 메소드에 입력 매개 변수가있는 경우 해당 매개 변수가 무엇인지 예상해야합니다. 응용 프로그램 내의 상황과 장소에서는 상황이 다릅니다. 예를 들어, 메소드 또는 코드가 사용자 입력의 데이터를 승인하는 경우 모든 코드 기반을 다루고 오류 메시지를 통해 또는 허용 할 수없는 데이터를 표시하는 좋은 방법을 통해 모든 입력을 처리하려고합니다.

메소드가 노출 된 API ditto 인 경우 들어오는 내용을 제어 할 수 없으므로 모든 측면과 프로그램을 적절하게 다루려고 노력해야합니다.

프로젝트의 핵심 엔진 내에서 생성 된 방법의 경우 결정을 내립니다. 도착하는 데이터가 도착하기 전에 사전 검사되고 유효성이 검사되었거나 필요한 점검을 수행해야한다고 가정합니까? 나는 이것이 방법의 개념 수준과 이것이 수용 가능한 장소인지에 달려 있다고 생각합니다. 그래서 내가 고려해야 할 것은 다음과 같습니다.

1)이 검사를 수행해야하는 유일한 장소입니까? 이 변수는이 조건에 대해 많은 다른 장소에서 확인해야합니까? 그렇다면 체인을 한 번 더 높이 검사하고 나중에 유효성을 가정 할 수 있습니까?

2) 시스템의 다른 구성 요소는 내가 작성한 방법 및 인터페이스와 함께 작동 할 것으로 예상됩니다. 그렇다면 디버그 어설 션 문, 디버깅 예외, 메서드 주석 및 일반 시스템 아키텍처를 통해 필요한 결과를 제어 할 수 있거나 데이터 검사가 필요합니다.

3) 코드에서이 시점에서 실패의 결과는 무엇입니까? 전체가 고장 날까요? 다른 곳에서 오류가 발생하고 최소한 그 오류가 발생합니다.

4) 여기에 체크를하는 것이 합리적입니까? 때때로 오류가 아닌 해당 지점의 문제를 해결하는 데 도움이되지만 손상된 데이터 일부를 검사하면 오류를 해결하지 못할 수 있습니다. 이 시점에서 실제 문제를 찾기 위해 다른 문제를 추적하는 데 몇 시간을 소비 할 수있는 것은 사용자 / 개발자가보고 한 이벤트에 연결된 이벤트 체인에서 데이터에 대한 유효한 확인 때문이었습니다.

일반적으로 나는 방어적인 프로그래머이지만 철저한 TDD 및 적절한 단위 테스트를 통해 필요한 수준에서 코드에 체크를 넣고 하위 레벨 섹션에 도달하면 작동하는지 확신 할 수 있다고 생각합니다. .

나는 몇 주 전에 이와 같은 5 분의 추가 작업으로 감지 될 수있는 버그를 보냈다. 내 생각에이 선행 작업은 항상 가치가 있습니다. 결국 버그를 수정하게됩니다. 유일한 질문은 시간이 얼마나 걸리는지입니다.

이러한 종류의 분석 도구가 종종 발견하는 것 중 하나는 반드시 버그 일 필요는 없지만 버그가 발생할 가능성이 높은 나쁜 프로그래밍 습관입니다. 이러한 일반적인 습관 중 하나는 변수 초기화입니다. 때때로 빈 문자열은 변수에 대해 완벽하게 유효한 값입니다. 이 경우 해당 특정 인스턴스의 오류를 고려하지 않도록 도구를 구성하려고합니다. 그러나, 종종 빈 문자열은 하지 변수에 유효한 값,하지만 존재하지 않는 경우 컴파일러가 불평을하기 때문에 사람들은 어쨌든 그것을 설정하는 뭔가 가있는, 또는 당신의 언어를 자동으로가 유효한지 여부 빈 문자열로 초기화합니다.

유효한 솔루션이없는 캐치 22처럼 보이기 때문에 사람들을 실망 시키지만 솔루션은 코드를 리팩터링하여 유효한 값이있을 때까지 변수를 초기화 할 필요가 없습니다. 이를 위해서는 약간의 추가 고려가 필요하지만 코드를 훨씬 강력하게 만들고 실제로 장기적으로 작성하고 유지 관리하기가 더 쉽습니다.