공격형 프로그래밍

Offensive programming

공격형 프로그래밍은 소프트웨어 버그로 인한 오류를 처리할 때 방어 원칙에서 명백히 벗어나는 방어형 프로그래밍의 분기에 사용되는 명칭이다.비록 그 이름이 방어적 프로그래밍에 대한 극단적인 해석에 대한 반응이지만, 두 사람은 근본적으로 대립하고 있는 것은 아니다.오히려 공격형 프로그래밍은 잘못된 장소에서 오류를 용납하지 않는 명백한 우선 순위를 추가한다. 즉, 방어 프로그래밍의 극단적인 해석에서 출발하는 지점은 그러한 오류를 용인하는 가상의 안전 이익보다 프로그램의 방어선 내에서 발생하는 오류가 노골적으로 드러나는 것을 선호한다.[1][2]이 선호도 또한 주장을 사용하는 것을 정당화하는 것이다.

구분오류

공격형 프로그래밍의 전제는 프로그램 방어선 밖에서 발생되는 예상 가능한 오류와 프로그램 모든 소프트웨어 구성요소가 예상대로 동작할 경우 발생하지 않는 방지 가능한 내부 오류를 구별하는 것이다.

대조적인 예:

예상 오류 예방 가능한 오류
잘못된 사용자 입력 잘못된 함수 인수
OS 리소스(예: 스토리지, 메모리) 고갈 값이 정의된 범위를 벗어남(예: 열거형)
하드웨어 장애(예: 네트워크, 스토리지) 기록되지 않은 반환 값 또는 예외

버그 탐지 전략

공격적인 프로그래밍은 실패와 관련이 있으므로 프로그래머의 가정을 반증한다.오류 메시지를 생성하는 것은 부차적인 목표가 될 수 있다.

전략:

  • 불필요한 검사 없음:다른 소프트웨어 구성요소가 지정된 대로 동작하므로 알 수 없는 문제에 대해 문서화하지 않도록 하는 것이 기본 원칙이다.특히, 일부 오류는 (프로그래밍 언어 또는 실행 환경에 따라) 이미 프로그램 중단을 보장할 수 있다(예: null 포인터를 무시).이와 같이, null 포인터 검사는 프로그램을 중지하기 위한 목적으로 불필요하다(단, 오류 메시지를 인쇄하는 데 사용할 수 있다).
  • 주장 – 비활성화할 수 있는 점검 – 소프트웨어 구성 요소 간의 설계 계약과 같이 점검할 필요가 없는 사항을 점검하기 위한 선호되는 방법이다.
  • 폴백 코드(림프 모드) 및 폴백 데이터(기본값):이것들은 주 구현의 결함을 숨길 수 있거나, 사용자 관점에서는 소프트웨어가 최적으로 작동하고 있다는 사실을 숨길 수 있다.아직 구현되지 않은 코드는 단위 테스트 실패에 의해 발견 가능한 테스트 주도 개발 단계가 아니기 때문에 구현되지 않은 부품에 대한 각별한 주의가 필요할 수 있다.
  • 바로 가기 코드 제거(전략 패턴 참조):단순화된 코드 경로는 일반 코드가 거의 실행되지 않는 경우 더 일반적인 코드 경로에 버그를 숨길 수 있다.두 사람이 같은 결과를 내야 하기 때문에 단순화된 결과는 없앨 수 있다.

참고 항목

참조

  1. ^ "Offensive Programming". Cunningham & Cunningham, Inc. Retrieved 4 September 2016.
  2. ^ Broadwall, Johannes (25 September 2013). "Offensive programming". Thinking Inside a Bigger Box. Retrieved 4 September 2016.