로에디 그린 - 유지보수하기 어렵게 코딩하는 방법

"평생 개발자로 먹고 살 수 있다"는 부제를 가진 이 책은 정말 제목대로 유지보수하기 어렵게 코드를 작성하는 방법이 나와있다. 그렇다고 부제처럼 자기만 알아볼 수 있는 코드를 작성해서 평생 짤리지 않도록 하는 방법을 다뤘다기 보다는, 나쁜 예를 보여서 이렇게는 하지 말자고 반성하게 하는 거울과 같은 역할을 하는 책이다.

읽다보니 정말 별의별 상황이 다 있는데, 어찌보면 내가 겪어본 것도 있고, (의도적이 아니었더라도) 내가 하고 있어서 반성하게 하는 부분도 있었다. 몇가지를 옮겨보면 아래와 같다.

"언어의 규칙이 허용하는 범위 내에서 클래스, 생성자, 메소드, 멤버 변수, 파라미터, 지역 변수에 같은 이름을 사용하자. 이에 안주하지 말고 더 나아가서 {} 블록 내에서 이미 사용되고 있는 지역 변수명을 재사용할 수 있는지 고민하자."

"이유는 빼고 어떻게에 대해서만 문서화하라"

"피트, 미터, 통과 같은 측정 단위를 변수, 입력, 출력, 매개변수에 문서화는 절대 하지 않는다."

"에러나, 기기 크래쉬, OS 결함을 처리하는 코드는 절대 테스트 하지 않는다. OS가 반환하는 코드도 검사하지 않는다. OS가 반환하는 코드는 실행에 아무 도움이 되지 않으며 우리 테스트 시간만 오래 걸리게 한다. 게다가 우리 코드가 디스크 에러, 파일 읽기 에러, OS 크래쉬와 같은 모든 경우를 적절하게 처리하는지 어떻게 일일이 테스트 할 수 있겠는가? 도대체 왜 컴퓨터 시스템을 신뢰할 수 없는 것처럼 생각하고 교수대 같은 것이 제대로 동작하지 않는지 테스트해야 하는지 이해할 수가 없다. 최신 하드웨어에서는 에러가 발생하지 않는다."

"프로그램이 좀 느리다고? 고객에게 더 빠른 컴퓨터를 사라고 말하자. 성능 테스트를 수행했다면, 문제가 일어나는 지점을 찾았을 것이다. 아마 문제를 해결하려면 알고리즘을 변경해야 할 것이고 제품 전체를 완전히 다시 설계해야 하는 경우도 생길 수 있다."

"개발 도구에 포함된 라이브러리를 모른척해야 한다. 비주얼 C++을 사용한다면 MFC나 STL의 존재를 무시하고 문자열이나 배열을 손수 작정할 수 있다. 이렇게 하면서 자신도 모르게 포인터 기술이 좋아지고 동시에 코드를 확장하려는 시도를 좌절시킬 수 있다."

이 책은 무료 e-book으로 공개되어 다운로드도 가능하고, 웹사이트에서 기사 형식으로도 공개되어있다.

e-Book

• e-Book 링크

글

• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(1)
  
• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(2)
• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(3)
• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(4)
• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(5)
• [한빛네트워크] 유지보수가 어렵게 코딩하는 방법(6)