프겔의 영원한 명저 "유지보수를 어렵게 코딩하는 방법"이라는 책에는

너무 코드를 친절하게 가독성이 높게 작성하면 쉽게 짤리고, 초급을 불러다가 유지보수를 시키니

최대한 코드를 어렵게 가독성은 낮게 짜서 나만 유지보수를 하게 하여 오래 먹고 살자는 취지의 책이다.



일부를 살펴보자


-문서화 편-


주석에 거짓말을 추가하라

적극적으로 거짓말을 할 필요는 없다. 그냥 자연스럽게 주석을 업데이트 하지 않아 내용이 맞지 않는 것처럼 보이게 하자.


명백한 사실을 문서화하라

코드에 /* add 1 to i */와 같은 양념을 추가한다. 중요한 점은 패키지나 메소드의 전체 목적과 같은 어려운 부분은 절대 문

서화하지 않는다는 사실이다.


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

프로그램이 무엇을 하는지에 대한 세부 사항 그리고 프로그램이 무엇을 달성하지 않는 것인지에 대해 문서화하라. 버그가 생

기면 수정을 담당하는 프로그래머는 해당 코드가 무엇을 수행해야 하는지 알 수 없게 된다.


“명백하게” 문서화하지 말아라

예를 들어, 항공기 예약 시스템을 구현하고 있는데 다른 항공편을 추가하려면 25 군대를 수정해야 한다고 가정하자. 물론 어

디를 수정해야 할지를 문서화하면 안 된다. 나중에 누군가 우리 코드를 수정하려면 전체 라인을 완벽하게 이해해야만 원하

는 수정을 할 수 있을 것이다.


문서화 템플릿의 적절한 활용

함수 문서화 프로토타입을 이용해 자동으로 코드에 문서화 틀을 제공할 수 있다. 이 때 다른 함수(혹은 메소드나 클래스)에

서 복사해서 사용하고 절대 필드에는 문서화 틀을 사용하지 말아야 한다. 어쩔 수 없이 필드에 문서화 프로토타입을 사용해

야 한다면 모든 함수에서 같은 파라미터 이름을 사용하도록 하고 주의사항도 같게 하자. 물론 이 주의사항이 현재 함수와 전

혀 관련이 없는 것일수록 좋겠다.


문제점

코드의 문제점을 문서화하지 않는다. 클래스에 버그가 있을 수 있다는 사실을 발견했으면 혼자만의 비밀로 간직한다. 코드를 

어떻게 재조직하거나 재작성해야 할지 아이디어가 떠올랐을지라도 문서로 남겨놓지 않는다. 영화 밤비(Bambi)에서 귀염둥

이 썸퍼(Thumper)의 말을 기억하자. “좋은 말을 하지 않으려거든, 그 입 닫으라”. 코드를 만든 프로그래머가 우리의 주

석을 보고 어떻게 생각하겠는가? 회사 사장이 본다면? 고객이 본다면? 심지어 해고될 수 있다. “수정해야 함!”이라는 익

명의 주석을 활용할 수 있다. 특히 이 주석이 어느 부분을 가리키는 것인지 명확하지 않을수록 좋다. 내용을 되도록 흐지부

지하게 만들어서 누군가를 비난하고 있다는 느낌이 들지 않도록 주의해야 한다.


변수 문서화

변수 선언에는 절대로 주석을 달지 않는다. 변수를 어떻게 사용해야 하고, 경계 값은 무엇이며, 사용할 수 있는 값은 무엇이

고, 함축된/표시된 십진수 점, 측정 단위, 표현 형식, 데이터 입력 규칙(전체 값을 채워야 하는지, 반드시 입력해야 하는 지

와 같은), 값을 신뢰할 수 있는 조건 등과 같은 정보는 코드를 통해 충분히 얻을 수 있다. 주석을 기록하도록 상사가 강요한

다면 메소드 바디에 변수를 넣어서 사용하자. 그러나 이 경우에도 절대 임시로라도 변수 선언에 주석을 추가하면 안된다.


폄하하는 말을 주석에 사용하기

외부 회사와 유지보수 계약을 체결할 수 없도록 다른 소프트웨어 선도 업체를 폄하하는 글을 추가한다. 특히 현재 회사와 계

약할 수 있는 가능성이 있는 회사를 공격할수록 좋다. 예를 들면, 다음과 같다.

/* 내부 루프 최적화 

Software Services Inc.,의 굼뱅이들은 아래와 같은 코드를 꿈에도 몰랐겠지.

그 녀석들은 아마 답답한 <math.h>의 기능을 이용해서 50배나 느리고 메모리도 많이 사용했을 꺼야.

*/ 

class clever_SSInc 

    { 

    .. . 

    } 

가능하다면 주석 뿐만 아니라 코드 구문상 중요한 부분에 모욕적인 발언을 추가하는 것이 좋다. 그러면 나중에 유지보수가 

필요할 때 관리자는 해당 코드를 제거하려고 애쓸 것이다.


펀치 카드의 코볼(CØBØL)을 사용한 것처럼 주석을 추가하라

개발 환경 분야의 발전 특히, SCID 등의 사용을 거부하라. 모든 함수와 변수 선언이 한번의 클릭으로 가능할 것이라는 헛소

문에 현혹되지 말자. 비주얼 스튜디어 6.0으로 개발한 코드는 edlin이나 vi를 사용하는 개발자가 유지보수 할 것이라 가정하

자. 드라콘 식의 주석 규칙을 따르는 것이 소스 코드를 올바로 작성하는 것이라는 신념을 갖자.


오늘은 여기까지