이 글은 농담일 뿐이다! 혹시라도 이 글의 내택을 있는 그대로 받아들인 이가 있다면 정중히 사과한다. 캐나다 사람은 농담에 :-)를 삽입하는 것을 세련되지 못한 행동으로 받아들인다. 내가 유지보수할 수 있는 코드를 작성하는 방법에 관해 지껄일 때면 사람들은 별로 관심을 가지지 않았다. 어느 날 일을 그르치는 얼간이 같은 행동을 얘기해야 사람들이 더 반응을 보인다는 사실을 알게 됐다. 유지보수 할 수 없는 디자인 패턴을 확인하므로 더 효과적으로 악의적인 혹은 부지불식간에 일어나는 나쁜 일을 예방할 수 있다
잡다한 기법
누군가에게 프로그램을 주면 하루 만에 그를 좌절시킬 수 있다. 그러나 프로그램을 어떻게 사용하는지를 알려줌으로써 그를 평생 좌절시킬 수 있다.
- 아무개씨
재컴파일 하지 마라
가장 사악한 기법부터 살펴보자. 컴파일에 성공해서 실행파일을 만들었다면, 각 모듈에서 소스코드 몇 개를 수정하자. 그러나 이들 파일을 애써 재컴파일할 필요까진 없다. 나중에 디버깅 할 시간이 남았을 때 재컴파일 하면 된다. 운이 지지리 없는 유지보수 프로그래머가 몇 년 후에 코드를 수정하지만 프로그램이 제대로 동작할 리 없다. 아마도 그녀는 자신이 수정한 뭔가에 문제가 있다고 생각할 것이다. 이와 같은 기법으로 우리는 그녀를 몇 주 동안 바쁘게 만들 수 있다.
디버거 차단
줄을 길게 만들어서 디버거를 이용해서 한 줄씩 우리 코드를 이해하려는 사람을 좌절시킬 수 있다. 특히 브레이크 포인트를 잡기 어렵게 if와 then을 한 줄에 모두 사용하면 더욱 효과적이다. 그러면 분기문이 어느 문장을 수행하는 것인지 구별하기가 어려워진다.
S.I. vs 미국식 단위
엔지니어링 작업을 할 때 두 가지 방법으로 코드를 만들 수 있다. 하나는 모든 입력을 S.I.(미터법) 단위를 사용하고 나중에 결과를 돌려줄 때에는 사람들이 이용하는 단위로 변환할 수 있다. 다른 방법은 여러 단위를 다양하게 시스템 전체에서 혼합해 사용하는 것이다. 물론 항상 두 번째 방법을 이용하는 것이 좋다. 그게 미국식이다!
CANI
상수 그리고 절대 끝나지 않는 개선작업(Constant And Never-ending Improvement). 우리가 코드를 "개선"하면 사용자도 업그레이드해야 한다. 결국 오래된 버전을 원하는 사람은 아무도 없기 때문이다. 프로그램 자체로도 그렇게 좋아한다면, 문제를 "수정"한 버전을 내놓았을 때에는 얼마나 기뻐할지 생각해보라! 누군가가 묻지 않는 한 절대 버전 변경의 차이를 말하지 마라. 알려주지 않았으면 알아차리지도 못했을 예전 버그를 왜 알려줘야 하는가?
프로그램 정보
프로그램 정보란에는 프로그램 이름, 코더 이름, 난해한 법률용어를 포함하는 저작권 등을 포함한다. 이 화면에서 재미있는 애니메이션을 보여주는 코드를 실행하는 링크가 있다면 금상첨화다. 그러나 프로그램 정보란에 프로그램의 목적, 마이너 버전, 최신 코드 리비전 날짜, 업데이트를 얻을 수 있는 웹사이트, 저자의 이메일 주소 등은 절대 명시하지 말아야 한다. 이렇게 시간이 흐르면 많은 이들이 각자 서로 다른 버전을 사용하게 할 수 있다. 때로는 N+1 버전을 설치하지도 않고 N+2 버전을 설치하려 하는 이도 있을 것이다.
변화, 변화, 변화하라
버전마다 더 많은 변화를 줄수록 좋다. 사용자가 예전 API나 오래된 사용자 인터페이스를 사용하면서 지루해 하는 것을 원하는 사람은 아무도 없다. 그러나 사용자가 알지 못하는 변경을 하는 것도 나쁘진 않다. 결국 이 모든 변화는 사용자를 긴장시키고, 현실에 안주하지 않게 채찍질 할 것이다.
개별 파일에 C 프로토타입을 추가하라
공통 헤더를 사용하지 않고 개별 파일에 C 프로토타입을 추가하므로 파라미터 데이터 형식을 모든 파일에서 유지하게 하고 컴파일러나 링크가 형식 불일치를 검출하지 못하게 하는 일석 이조 효과를 얻을 수 있다. 이는 32비트에서 64비트 플랫폼으로 포팅할 때 특히 유용하다.
특별한 기술은 필요없다
큰 기술이 있어야 유지보수 할 수 없는 코드를 작성할 수 있는 것은 아니다. 그냥 잡히는 대로 코딩을 시작해보자. 대부분의 관리자는 우리가 만든 코드 줄 수로 생산성을 판단하는 경향이 있다. 따라서 나중에 삭제할 쓸모 없는 코드라도 일단 넣어보자.
한 개의 망치만 사용한다
자신이 잘 아는 도구를 사용해 가볍게 여행하자. 망치 하나만 있으면 모든 문제는 못에 불과하다.
표준을 무시하라
가능하면 프로젝트를 진행하는 언어와 환경에서 수 천명이 사용하는 코딩 표준을 무시해야 한다. 예를 들어 MFC 기반 응용 프로그램을 만들면서 STL 스타일의 코딩 표준을 따르겠다고 주장하자.
일반적인 True, False 규칙을 뒤집어라
일반적인 true, false에 대한 정의를 뒤집어라. 보기보다는 파급효과가 크다. 아래와 같은 정의를,
#define TRUE 0
#define FALSE 1
아무도 잘 찾아보지 않을 코드 깊은 곳에 숨겨야 한다. 그리고 프로그램에서는 아래와 같은 비교문을 사용할 수 있다.
if ( var == TRUE )
if ( var != FALSE )
누군가 위와 같은 중복 문제를 "수정"해서, 다음과 같이 정상적인 방법으로 사용할 가능성도 있다.
if ( var )
완전한 사기처럼 보일 수 있겠지만 TRUE와 FALSE가 같은 값을 갖도록 하는 기법도 있다. 1과 2 또는 -1과 0과 같이 교묘하게 변경하는 방법도 바람직하다. 자바에서도 TRUE라는 이름의 정적 상수를 정의함으로써 이 기법을 사용할 수 있다. 자바에는 true라는 내장어가 이미 있기 때문에 우리의 의도를 의심하는 프로그래머가 등장할 수 있다.
서드 파티 라이브러리
프로젝트에 막강한 서드 파티 라이브러리를 포함하고는 사용하지 않는다. 추가하고 사용하진 않았지만, 우리의 이력서 "기타 도구" 부분에 사용하지 않았던 도구 이름을 추가할 수 있다.
라이브러리를 피하라
개발 도구에 포함된 라이브러리를 모른척해야 한다. 비주얼 C++을 사용한다면 MFC나 STL의 존재를 무시하고 문자열이나 배열을 손수 작정할 수 있다. 이렇게 하면서 자신도 모르게 포인터 기술이 좋아지고 동시에 코드를 확장하려는 시도를 좌절시킬 수 있다.
빌드 순서를 만들라
빌드 순서를 정교하게 만들어서 유지보수 프로그래머가 자신이 수정한 파일을 컴파일 하지 못하게 할 수 있다. 숨겨진 SmartJ를 이용해서 make 스크립트를 무용지물로 만들자. 비슷한 방식으로 컴파일러를 클래스로 사용할 수 있다는 사실도 비밀로 간직해야 한다. 죽는 한이 있더라도 파일을 찾고, 직접 컴파일 클래스 sun.tools.javac.Main를 호출하는 간단한 자바 프로그램을 만드는 일이 얼마나 쉬운지를 절대 발설하지 말자.
Make를 이용한 장난질
여러 디렉터리에서 소스를 복사하는 배치 파일을 Make파일로 생성한 다음 어떤 규칙으로 파일을 복사하는지는 문서화하지 않는다. 이 기술을 사용하면 멋진 소스 코드 관리 시스템 없이도 코드 가지치기(branching)를 할 수 있으며 후임자가 어떤 버전의 DoUsefulWork()을 수정해야 하는지 절대 찾을 수 없게 만들 수 있다.
코딩 표준을 수집하라
내가 아니라, IDE!
모든 코드를 makefile로 만들어라. 후임자는 헤더파일을 생성하고 응용 프로그램을 빌드하는 배치파일을 생성하는 makefile을 만들었다는 사실에 감탄할 것이다. 그리고 이를 변경했을 때 어떤 일이 일어날 것인지 알기 어렵고 최신 IDE로 프로젝트를 옮기기도 어렵게 만들 수 있다. 그리고 이미 뇌사 상태에 들어간 NMAKE 버전을 종속성 개념 없이 사용하므로 효과를 극대화 할 수 있다.
회사 코딩 표준을 무시하라
몇몇 회사에서는 프로그램에 숫자 기호 사용을 금지하는 등과 같은 강력한 정책을 적용한다. 이 경우에는 어쩔 수 없이 상수에 이름을 붙여 사용해야 한다. 물론 정책을 와해시키는 것은 간단하다. 예를 들어, 똘똘한 C++ 프로그래머는 다음과 같이 상수를 정의했다.
#define K_ONE 1
#define K_TWO 2
#define K_THOUSAND 999
컴파일러 경고
컴파일러 경고를 모두 수정하지 말고 남겨두는 것이 좋다. Make 파일에 접두어 "-"를 사용하므로 컴파일 에러로 make가 실패하는걸 방지할 수 있다. 실수로 유지보수 프로그래머가 소스 코드에 에러를 저질렀더라도 make는 전체 패키지를 다시 빌드하려 할 것이다. 심지어 운이 좋으면 빌드에 성공한다! 우리 코드를 손수 컴파일 해본 프로그래머라면 컴파일에 실패할 것이고, 기존 코드나 헤더에 자신이 무엇을 잘못 추가했는지 확인하려 할 것이다. 하지만 결국 유지보수 프로그래머는 모든 버그가 원래부터 있었던 것임을 알고는 이를 찾으려 애써야 했던 즐거웠던 경험에 대해 우리에게 감사해 할 것이다. 컴파일러의 몇몇 에러 확인 진단 옵션을 사용하면 우리 프로그램이 컴파일되지 않을 수 있다. 컴파일러는 경계 값 확인 등의 기능을 수행할 수 있지만, 실제 업무에서 이 기능을 사용하는 프로그래머는 거의 없으므로 우리도 이런 기능을 사용할 이유가 없다. 이런 미묘한 버그를 찾는 기쁨과 즐거움을 컴파일러에게 빼앗긴다니 말이 되는가?
버그 수정과 업그레이드를 혼합하라
절대 "버그만 수정한" 버전을 릴리즈 하지 말아라. 버그를 수정했으면 데이터베이스 형식도 바꾸고, 복잡한 사용자 인터페이스도 변경하고, 관리자 인터페이스도 다시 만들자. 이렇게 하면 사람들은 그냥 버그에 익숙해지려 하고 결국 버그를 기능이라 부르기 시작할 것이다. 단지 이런 "기능"이 다른 방식으로 동작하길 바라는 사용자만이 새로운 버전으로 업그레이드 할 필요성을 느낄 것이다. 이런 방식으로 유지보수 작업을 줄일 수 있고, 고객으로부터 얻는 수익도 늘어난다.
제품을 릴리즈 할 때마다 파일 형식을 변경하라
미래 호환성을 원하는 고객이 많으므로 원하는 대로 해주자. 그러나 기존 버전과의 호환성은 유지하지 않는 것이 핵심이다. 그러면 민감한 버그 수정 정책(윗글 참조)과 함께 나온 새로운 버전이 나왔을 때, 고객이 한번 새로운 버전을 사용하기 시작했다면 다시 이전버전으로 돌아갈 수 없게 된다. 결국 고객은 새로운 버전이 나와도 업그레이드를 선택하지 않을 것이다. 추가 보너스 팁! 새로운 버전에서 생성한 파일을 예전 버전에서 인식조차 못하게 하는 방법은 무엇이 있을까? 이런 방법을 이용해 심지어는 같은 응용 프로그램으로 만든 파일이 아니라고 거부할 수 있다. PC 워드 프로세서에서 이러한 복잡한 동작과 관련한 예제를 제공한다.
버그를 보상하라
코드에서 버그의 근본 원인을 찾아내는 것을 두려워하지 말고 고수준 루틴에 이를 보상할 수 있는 코드를 넣자. 이는 3D 체스와 같은 지능 활동의 산물이다. 이 덕분에 이후에 작업할 유지보수 프로그래머는 문제가 데이터를 생성하는 저수준 루틴에서 발생한 것인지 아니면 값을 변경하는 고수준 루틴에서 발생한 것인지를 찾는 즐거움에 빠져 수많은 시간을 보내야 할 것이다. 이 기법은 멀티 패스 프로그램인 컴파일러에 적합하다. 첫 번째 과정에서는 문제 수정을 회피함으로써 나중 과정을 더욱 복잡하게 만들 수 있다. 운이 좋으면 컴파일러의 프론트엔드 유지보수를 담당자에게 이 부분에 대해 얘기할 필요가 없는 경우도 있다. 프론트엔드에서 데이터를 정확하게 만든 경우 백엔드가 멈추게 하면 더욱 좋다.
스핀 락(Spin Lock)을 활용하라
스핀 락을 사용하고 기본 동기화 기능을 사용하지 말아라. 반복적으로 슬립 상태에 빠지면서 전역 변수(비휘발성의)를 통해 조건을 만족하는지 확인하자. 스핀 락은 시스템 오브젝트보다 더 "일반적"이고 "유연"하며 사용하기 쉽다.
동기화 코드를 마구 뿌려대라
꼭 필요하지 않은 곳이라 하더라도 시스템 동기화 코드를 추가해보자. 필자는 코드에서 두 번째 스레드가 실행할 가능성이 전혀 없는 크리티컬 섹션을 우연히 발견했다. 기존 개발자를 한번 시험해 봤고, 그는 해당 코드가 "비난받기(critical)!" 마땅하다고 시인했다.
우아한 타락
시스템에 NT 디바이스 드라이버를 사용한다면, 응용 프로그램에서 I/O에 필요한 버퍼를 요구하고 트랜잭션이 일어나는 동안 버퍼에 락을 걸도록 요청하자. 그리고 나중에 버퍼를 언락하고 해제한다. 응용 프로그램이 버퍼에 락을 건 상태로 비정상적으로 종료하면 NT 자체의 크래쉬를 발생시킬 수 있다. 클라이언트 사이트에서는 디바이스 드라이버를 바꿀 방법이 없으므로 선택의 여지는 없다.
커스텀 스크립트 언어
우리의 클라이언트/서버 응용 프로그램에서 실행 중에 바이트로 컴파일되는 스크립팅 명령어 언어를 포함해야 한다.
컴파일러 종속 코드
컴파일러나 인터프리터 버그를 발견했으면 이 버그를 이용해 우리 코드가 제대로 동작하게 만들자. 이제 우리 프로그램을 사용하는 모든 이는 다른 컴파일러를 사용할 수 없게 된다.
실생활 예제
스승님께서 작성하신 실생활 예제를 보여주겠다. 하나의 C 함수에 그가 사용한 여러 기법을 살펴보자.
void* Realocate(void*buf, int os, int ns)
{
void*temp;
temp = malloc(os);
memcpy((void*)temp, (void*)buf, os);
free(buf);
buf = malloc(ns);
memset(buf, 0, ns);
memcpy((void*)buf, (void*)temp, ns);
return buf;
}
- 자세히 보면 Realocate의 철자가 부정확하다. 창의적인 철자법의 힘을 얕보지 말라.
- 아무런 이유 없이 입력 버퍼를 임시 복사본을 만든다.
- 이유 없이 형을 변환한다. Memcpy()는 (void*)형을 매개변수로 받으므로 이미 (void*)형을 사용하더라도 무조건 형변환한다.
- temp를 해제할 필요는 없다. 이렇게 작은 메모리 누수의 효과는 미미하기 때문에 며칠 동안 프로그램을 돌려도 끄떡없는 경우가 많다.
- 만약을 대비해서 버퍼에서 필요한 데이터 이상을 복사하라. 유닉스에서는 코어 덤프가 발생할 것이다.
- 위 코드에서 os는 "old size"를 ns는 "new size"를 의미하는 듯 하다.
- 표준 라이브러리에 이미 있는 간단한 함수는 다시 만든다.
- buf를 할당하고 0으로 memset한다. 누군가 ANSI 스펙을 변경할 가능성이 있으므로 calloc()을 사용하는 것은 위험하다(일단 어차피 buf 크기와 동일한 데이터를 복사한다는 사실은 신경쓰지 말자).
사용하지 않은 변수 에러를 고치는 방법
컴파일러에서 "사용하지 않은 지역 변수" 경고를 발생한다고 해서 그 변수를 꼭 없앨 필요는 없다. 대신, 창의적으로 고민을 좀 해보자. 나같으면…
i = i;
중요한 것은 크기
함수가 크면 클수록 좋다는 것은 두말하면 잔소리인 진리다. 물론 jump와 GOTO도 많을수록 좋다. 이렇게 할 때 누군가 무엇을 변경하게 되면, 검증해야 할 시나리오가 정말 다양해 진다. 이제 코드 스스로가 유지보수 프로그래머에게서 자신을 보호할 수 있게 된다. 함수를 거인 왕처럼 만들 수 있다면 함수는 고질라가 되어 유지보수 프로그래머가 무슨 일인지 정신을 차리기도 전에 공격하고 무자비하게 밟아버릴 것이다.
하나의 그림은 1000개의 단어를 대신하고, 하나의 함수는 1000개의 줄을 대신한다.
모든 메소드의 바디를 가능한 한 길게 만들어라. 깊게 중첩하는 것을 잊지 말고 절대 앞으로는 1000줄 이하의 메소드나 함수를 만드는 일이 없도록 하라.
사라진 한 개의 파일
중요한 파일이 적어도 한 개 이상이 없어지게 해야 한다. 이 기법은 include에 include를 혼합하므로 효과를 극대화할 수 있다. 예를 들어, 우리 모듈에서
#include <stdcode.h>
Stdcode.h는 존재한다. 그러나 stdcode.h에서 가리키는
#include "a:\refcode.h"
Refcode.h 파일은 어디에서도 찾을 수 없어야 한다.
여러 곳에서 작성하고 어디에서도 읽을 수 없게 하라
적어도 한 변수를 모든 곳에서 설정하도록 하고 사용하는 곳이 없게 하라. 불행히도 현대 컴파일러는 아무데서도 기록하지 않고 모든 곳에서 읽는 동작을 허용하지 않는다. 하지만 C나 C++에서는 이러한 동작을 아직 수행할 수 있다.
철학
컴파일러나 시스템 클래스를 만드는 사람이 보통 언어를 설계한다. 당연한 일이지만, 그들은 자신의 작업을 용이하게 수학 계산을 간단히 할 수 있는 방식으로 언어를 설계한다. 그러나 한 컴파일러를 구현하는 사람 뒤에는 10,000 명의 유지보수 프로그래머가 필요하다. 정작 힘들게 일하는 유지보수 프로그래머는 언어 설계 단계에서 의견을 내지 못한다. 그러나 유지보수 프로그래머가 작성한 코드 양에 비하면 컴파일러 코드는 한없이 작을 뿐이다.
이런 엘리트 주의적인 생각은 JDBC 인터페이스에서 잘 나타난다. JDBC 인터페이스는 JDBC 구현자의 삶을 쉽게 만들어 준다. 그러나 유지 보수 프로그래머에게는 악몽을 가져다 주었다. JDBC 인터페이스는 삼십년 전에 나온 포트란의 SQL 인터페이스보다 못하다.
유지보수 프로그래머는 세부사항은 감추어서 나무로 이루어진 숲을 볼 수 있게 해달라고 요청한다. 그들은 다양한 종류의 단축(shortcut) 방법을 이용해서 많은 코드를 타이핑하지 않아도 되고, 따라서 프로그램을 화면으로 확인하기 쉽게 해달라고 요청한다. 유지보수 프로그래머는 컴파일러가 요구하는 많은 하찮은 작업으로부터 해방시켜 달라고 큰소리로 불평한다.
이와 같은 노력에 부흥하는 결과로 현재 작업과 관계없는 세부 사항은 감출 수 있는
NetRexx, Bali 그리고 비주얼 편집기(예를 들어 IBM의 비주얼 에이지를 시작으로) 등이 소개됐다.
구두 제조인은 신발이 없다
자신의 원장을 워드 프로세서로 관리해 달라고 주장하는 회계사 고객이 있다고 가정하자. 아마 우리는 데이터를 구조화 한다고 그를 설득할 것이다. 그는 상호간의 필드 검사와 유효성 검사도 요구한다. 우리는 동시 업데이트를 지원하는 데이터베이스에 데이터를 저장하는 것이 유리하다고 그를 설득할 것이다.
소프트웨어 개발자 고객의 경우를 살펴보자. 그는 모든 데이터(소스 코드를) 텍스트 편집기에 보존해야 한다고 주장한다. 그는 아직 워드 프로세서의 색상, 형식 크기, 폰트 등을 사용해본 적이 없다.
소스 코드를 구조화된 데이터로 저장하면 무슨 일이 일어날까? 하나의 소스코드를 자바, NextRex, 의사결정 테이블, 플로우 차트, 루프 구조 뼈대(상세 내용 없이), 상세 내용이나 주석을 제거한 자바, 현재 관심이 있는 변수와 메소드 호출을 하이라이트한 자바 코드, 매개변수 이름과 형식에 대한 주석을 포함하는 자바 코드 등의 다양한 방식으로 볼 수 있다. 복잡한 수식 표현을 TeX나 수학자들이 하듯이 2차원으로 확인할 수 있다. 괄호를 추가하거나 뺀(자신의 우선순위 규칙 취향에 따라) 형태의 코드도 확인할 수 있다. 괄호는 다양한 크기와 색을 눈으로 구별하는데 유용하다. 선택적으로 제거하거나 적용할 수 있는 투명한 오버레이 집합을 사용해서 다른 나라에서 일하는 팀의 다른 프로그래머를 실시간으로 볼 수 있고 작업중인 코드 변경 사항도 확인할 수 있다.
색상을 이용해 미묘한 단서의 실마리로 사용할 수 있다. 예를 들어 각 패키지/클래스에 색상을 자동으로 지정해서 클래스의 메소드나 변수의 레퍼런스 백그라운드에 파스텔 그림자를 사용할 수 있다. 특정 식별자의 정의에 볼드체를 적용해서 두드러지게 할 수도 있다.
X 형식의 오브젝트를 생성하려면 어떤 메소드나 생성자를 사용해야 하는가? 오브젝트 X 형식을 파라미터로 받는 메소드는 어디 있는가? 코드에서 어떤 변수에 접근할 수 있는가?와 같은 질문을 할 수 있다. 메소드 호출이나 변수 레퍼런스를 클릭하면 관련 정의를 확인할 수 있고, 어떤 버전의 메소드가 실제 실행될 것인지 쉽게 확인할 수 있다. 지정한 메소드나 변수의 모든 레퍼런스를 확인하면서 체크 표시를 할 수도 있다. 가리키고 클릭하는 동작으로도 많은 일을 할 수 있으므로 코드를 직접 작성하는 일이 줄어든다.
위에서 살펴본 사항 중 몇 가지는 실현 불가능할 수도 있다. 어떤 것이 실생활에 꼭 필요한 것인지 알아보려면 부딪쳐 보는 수밖에 없다. 기본 도구를 얻었으면 유지보수 프로그래머의 생활을 개선할 수 있도록 수많은 아이디어를 실험해봐야 한다.
이에 대해서는 SCID 학생 프로젝트에서 더 설명하겠다.
이 글은 농담일 뿐이다! 혹시라도 이 글의 내용을 있는 그대로 받아들인 이가 있다면 정중히 사과한다. 캐나다 사람은 농담에 :-)를 삽입하는 것을 세련되지 못한 행동으로 받아들인다. 내가 유지보수할 수 있는 코드를 작성하는 방법에 관해 지껄일 때면 사람들은 별로 관심을 가지지 않았다. 어느 날 일을 그르치는 얼간이 같은 행동을 얘기해야 사람들이 더 반응을 보인다는 사실을 알게 됐다. 유지보수 할 수 없는 디자인 패턴을 확인하므로 더 효과적으로 악의적인 혹은 부지불식간에 일어나는 나쁜 일을 예방할 수 있다.
Git가 무엇인가?