Topic 25 단정적 프로그래밍
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
단정문으로 불가능 상황을 예방하라.
p.162
‘하지만 물론 그런 일은 절대 일어나지 않을 거야.’ 라는 생각이 든다면 그런 일을 확인하는 코드를 추가하라. 가장 간단하게 추가하는 방법은 단정문을 사용하는 것이다.
p.163
엘리자베스 퀴블러 로스(Elizabeth Kubler Ross)는 죽음을 수용할 때 부정, 분노, 타협, 우울, 수용의 단계를 거친다고 설명했다. 배포를 하고 버그가 리포팅되면 이와 같은 5단계를 거치게 되는 것 같다.
아니야… 이건 아니야… 불가능해… 버전 반영이 안 됐나… -> 왜 못 걸러냈지, 이게 어떻게 발생했지 -> 아냐 금방 원인 파악되면 쉽게 해결 될거야 -> 로컬에서는 되는데..? -> 로그 더 찍고 고쳐야겠다. 등을 거치게 되는 것 같다. 예시로 적어본 것은 엄청 농담 반 진담 반이다. 아마 꽤나 많은 개발자분들이 공감하실 부분 같다. 이런 일을 종종 겪게 되면 더 조심해지고 버그를 줄이도록 노력하는 스킬이 생기는거 같다.
예를 들어 코드를 다음과 같이 작성하는 것은 그리 좋은 생각이 아니다.
while (iter.hasMoreElements()) { assert(iter.nextElement() != null); Object obj = iter.nextElement(); // ... }단정문 안에 있는 .nextElement() 호출은 이 호출이 반환하는 원소 다음으로 반복자(iterator)를 이동시키는 부작용이 있다. 그러므로 이 반복문은 컬렉션의 원소 중 절반만 처리하게 된다. 다음과 같이 작성해야 한다.
while (iter.hasMoreElements()) { Object obj = iter.nextElement(); assert(obj != null); // … }
이는 디버깅 행위가 디버깅하려는 시스템의 행동을 바꿔 버리는 일종의 ‘하이젠버그(Heisenbug)’적인 문제다.
p.164
필자도 과거에 테스트 케이스를 작성하기 위해 로직에 if(ENV === ‘test’) {} 과 같이 실행 환경을 가지고 로직을 분기 처리하도록 코드를 작성한 적이 있다. 물론 코드 리뷰 때 ‘코드를 위해 테스트를 해야지 테스트를 위해 코드를 작성하면 안된다’는 리뷰와 함께 변경한 기억이 있다. 정말 지금도 기억할 정도로 소중하고 감사한 리뷰이다. 이러한 경험들을 통해 개발자로서의 가져야할 소중한 태도를 배웠기 때문이다. 물론 지금도 계속해서 배우고 있다. 하이젠버그를 보니 과거의 경험이 생각나서 필자의 경험을 적어보았다.
Topic 25 느낌
Topic 25 에서는 말도 안되는 경우라서 믿고 가는 것이 아니라 확인 절차를 만드는 어떻게 보면 새로운 관점을 알려주고있다.