<Code Craft> 1부 코드와 마주보기 : 01 방어하기 (1)

“우리는 서로를 믿지 말아야 합니다. 그것이 배신에 대한 유일한 방어책입니다.”

- 테네시 윌리암즈

훌륭한 코드를 향해서

 

작동하는 프로그램과 올바른 프로그램을 만드는 것의 차이

· 작동하는 코드를 작성하는 것은 쉽다. 평범한 입력을 넘겨주면 평범한 출력을 내놓지만 의외의 값을 넘겨주면 그냥 무너져 냉릴 수도 있다.

· 올바른 코드는 무너져 내리지 않는다. 있을 수 있는 모든 입력에 대해 올바른 출력을 내놓는다. 하지만 그런 일반적 입력 집합의 크기는 터무니 없이 크고, 올바른 코드인지 테스트하는것은 어렵다.

· 올바른 코드라 해서 모두 뛰어난 것은아니다. - 로직을 따라가기 어려울 수 있고 사실상 유지보수가 불가능 할수도 있다.

 

코드를 구축하는 방법은 여러가지가 있지만, 방어적 프로그래밍은 보편적을 ㅗ적용될 수 있는 접근 방법입니다. 잠재적인 코딩 문제가 쌓여가는 것을 방지하는 실무적인 방법이다.

 

최악을 가정하라.

추측은 결함 있는 소프트웨어의 작성 원인이 됩니다. 우리는 다음과 같은 추축을 하기가 쉽습니다.

· 해당 함수는 절대 그런식으로 호출되지 않을 거야, 항상 유효한 파라매터만 받을꺼야

· 코드의 이 부분에서는 항상 제대로 작동할 거야, 에러가 생기는 일은 없을 거야

· 변수에 “내부에서만 사용하는 변수”라고 문서화 해놓으면, 이 변수에 아무도 접근하려고 하지 않을 꺼야

 

방어적 프로그래밍은 아무것도 추측하면 안됩니다. “그런일은 절대 일어날리가 없어” 라는 추측은 절대 하지 말아야 합니다. 세상이 우리가 기대한 것 처럼 돌아갈 것 이라는 추측을 절대로 하지 말아야 합니다.

 

“잘못 사용될 가능성이 있는 것은 잘못 사용되고야 만다.”

- 에드워드 머피 주니어

 

방어적 프로그래밍이란?

방어적 프로그래밍이란 이름그대로 신중하고 경계를 하는 프로그래밍이다. 구성요소가 가능한 한 자기 자신을 많이 보호하도록 설계해ㅑ야 합니다. 문서화 되지 않은 추측은 코드 안에서 명시적인 체크를해서 격파할 수 있습니다.

 

아무생각없이 코드를 생산하는 프로페셔널 개발자들은 이렇게 전개됩니다.

1. 코드를 땜질한다.

2. 실행한다.

3. 에러가 난다.→ 1. 부터 반복

 

이러한 개발자들은 시간을 들여서 검증하지 않기 때문에 잘못된 추측에 끊임없이 걸려 넘어집니다.

방어적 프로그래밍의 전개 방식은 다음과 같습니다.

1. 코딩한다.

2. 테스트한다.

3. 작동한다.

 

방어적 프로그래밍에 대한 찬반 논란

반대론

· 방어적 프로그래밍은 프로그래머와 컴퓨터의 자원 모두 소모합니다.

· 효율성을 좀먹어 들어갑니다. 코드가 아주 약간 더 추가되더라도 몇개 더 실행을 해야합니다.

· 방어적 습관 하나하나가 몇가지 추가 작업을 더 필요로 합니다. 해야할 일이 많은데 다른사람이 당신의 코드를 확인만 하면 됩니다.

 

찬성론

· 방어적 프로그래밍은 실제 디버깅 시간을 절약해주고, 그동안 다른일을 더 많이 할 수 있다.

· 약간 느리짐나 올바르게 작동하는 코드는, 대부분 작동하지만 이따금식 에러를 내며 고장나는 코드보다 훨씬 낫습니다.

· 릴리즈 빌드에서 방어적 코드가 물리적으로 제거되게끔 설계할 수 있습니다. 그렇게하면 성능상 문제를 피해갈 수 있습니다.

· 현대적인 소프트웨어 개발의 중대 이슈인 수많은 봉나 관련 문제점들을 예방합니다.

 

다음의 사항은 방어적 프로그래밍이 아닙니다.

· 에러 체크

→ 발생 가능성이 있는 에러가 있으면 체크를 해야합니다. 이것은 단순히 좋은 습관입니다.

· 테스트

→ 테스트는 정상적인 개발 작업의 일부분입니다.

· 디버깅

→ 디버깅하면서 몇가지 방어적 코드가 추가될 수 있습니다. 하지만 디버깅은 프로그램이 에러가 난 다음 수행하는 것입니다. 방어적 프로그래밍은 고장이 나지 않도록 예방하는 것입니다.