항목 6 : 정확성, 간결성, 명확성을 먼저 생각하라. ( Correctness, simplicity, and clarity come first. )

이 정석은 평생 가장 익히기 힘든 것 중에 하나이다. 명언만 써도 바로 이해 될 수 있는 항목일 것이다.

프로그램은 사람이 읽을 수 있또록 쓰여져야 하고, 컴퓨터가 실행할 수 있도록 하는 것은 그 후의 문제이다. - 헤롤드 아벨슨, 제랄드 제이 수스맨

프로그램을 쓸 때는 사람을 먼저 생각하고, 컴퓨터는 두 번째로 생각하라 - 스티브 맥코넬

컴퓨터 시스템의 가장 값싸고, 빠르고 안정적인 구성 요소는 바로, 없는 요소이다 - 고든 벨

빠진 구성 요소야말로 가장 정확한 요소이며(절대 실수하지 않으므로), 가장 안전한 요소이며(부서질 수 없으므로), 디자인하고, 문서화하고, 테스트, 관리하기 가장 쉬운 요소이다. 간결한 디자인의 중요성은 아무리 강조해도 디나치지 않다. - 존 베틀리

이 모든 말은 "하나를 표현하는 것에 동등한 대안들이 있다면, 가장 단순한 것이 바로 답이다." 이것은 최소한 모든 프로그래머들의 진리 중 하나이다.

백범 김구가 말 했던 ( "하나의 진리로 만개의 변화에 대처한다." ) 것처럼, 모든 클래스 디자인, 모든 객체지향, 절차지향, 일반화 프로그래밍 부터 시작한 모든 것들은 이 가장 단순한 원리에서 시작한다.

내 경험으로는 "게임 네트워크 서버"를 만드는 중에, "링 버퍼"를 구현해야 될 상황이 생기게 되어, 구현을 하게 되었다. 문제는 바로 이 구현된 소스 코드를 다시 수정해야 될 상황이 놓이게 되었을 때 "막막함"을 느끼게 되었다. 무슨 행동을 하는 것인지 "파악"은 되나(내가 만들었으니..), 원하는 기능을 넣기 위해서, 어디를 고쳐야 하는지 "파악"되지 않았기 때문이다.

"파악"이 되지 않은 주된 원인은, 소스 코드가 너무 길고, 최적화가 들어간 터라, 변경하기 무척 까다로웠으며, 내부 함수가 여러 역활을 하게 되어, "파장"이 예상 되었기 때문이다.

결국 다 뜯어 고치는데 8시간이 걸렸다. 만약, "정확성, 간결성, 명확성을 먼저 생각했다면" 더 빠른 시간안에 더 좋게 변경을 했을 것이다.

총평

.. 진리이니 ... 코딩 순간 순간 떠올려야 할 것이다. 문제는 떠 올린다 해도, 그게 쉽게 잘 이루어 지지 못한다는 것이다. ; ) 오캄의 면도날은 어디에서나 사용 될 수 있는 무기임을 다시 한번 인지 한다.