등록일 : 2011년 07월 05일 조회수 : 3,339
저자 : 로에디 그린(Roedy Green)
원문 : Canadian Mind Products
서문
자신의 무능함을 남의 탓으로 돌리지 말라.
- 나폴레옹(Napoleon)
자바 프로그래밍 분야에 종사자가 많아지기를 바라는 마음에서 아래 팁을 전수하려 한다. 이 팁은 유지보수가 어려운 코드를 작성하기로 유명한 스승으로부터 전수받은 것이다. 사람들이 스승이 남겨놓으신 코드에 간단한 수정을 추가하는데도 몇 년 이상이 걸리곤 했다. 진심을 다해 아래 규칙을 지켜 코딩한다면 본인 외에는 누구도 그 코드를 유지보수할 수 없게 된다. 즉, 평생 직장을 보장받게 될 것이다. 혹은 모든 규칙을 진심으로 따른다면 본인조차도 자신이 만든 코드를 유지보수 할 수 없는 날이 올 것이다!
상황이 이 정도까지 극단적이 되길 원하는 사람은 없을 것이다. 우리가 만든 코드가 겉보기에도 유지보수 가망이 전혀 없는 코드처럼 보이는 상황은 피해야 한다. 그렇지 않으면 우리가 만든 코드를 리팩터리하거나 최악의 경우 다시 작성해야 하는 위험에 처할 수 있다.
일반 규칙
Quidquid latine dictum sit, altum sonatur.
- 라틴어에는 뭔가 특별한 것이 있다.
유지보수를 담당하는 프로그래머를 좌절시키려면 그가 생각하는 방식을 이해해야 한다. 유지보수 담당 프로그래머는 우리가 만든 거대한 프로그램을 넘겨받았다. 그가 모든 코드를 읽기는 힘들기 때문에 해당 프로그램에 대한 이해도가 우리보다는 낮은 편이다. 아마도 그는 가능한 한 빨리 수정할 곳을 찾아내어 코드를 수정한 다음, 해당 수정으로 발생하는 부작용이 없는지 확인하고 작업을 마무리하려 할 것이다.
유지보수 프로그래머는 화장실에 걸린 두루마리 휴지 관을 통해 우리 코드를 살펴보는 것과 마찬가지 상황에 처해있다. 그가 휴지 관을 통해 우리 코드를 보면서 전체적인 그림을 그려낼 수 없게 하는 것이 핵심이다. 그가 찾고 있는 코드를 가능한 한 찾기 어렵게 만들어야 한다. 더욱 중요한 사항은 그가 안심하고 코드를 무시할 수 있도록 가능한 한 서툴게 코드를 작성해야 한다는 점이다.
프로그래머는 규약(convention)을 통해 안심하는 습성이 있다. 간혹 조금이라도 규약 위반을 발견하면 그는 돋보기를 들고 코드 전체 라인을 샅샅이 조사할 가능성이 크다.
언어의 모든 기능이 코드 유지보수를 어렵게 만든다고 생각할지 모르지만, 이는 사실이 아니다. 오직 언어의 기능을 적절하게 오용해야 유지보수가 어려운 코드를 만들 수 있다.
이름 짓기
험프티 덤프티(Humpty Dumpty)는 다소 경멸적인 어조로 말했다. "내가 단어를 사용할 때에는 더도 덜도 아닌 딱 그 의미를 전달하려는 것이다."
- Through the Looking Glass, 6 장 중에서(루이스 캐롤(Lewis Carroll) 지음)
변수와 메소드의 이름을 짓는 방법은 유지보수 할 수 없는 코드를 작성하는데 있어 상당히 중요한 기술이다. 이름은 컴파일러에 영향을 주지 않는다. 이름 짓기 기술로 유지보수 프로그래머의 정신을 혼미하게 만들 수 있다.
태아 작명법의 새로운 용도
태아 작명법 서적을 구입하자. 그러면 변수명을 뭐로 지어야 할지에 대한 고민을 덜 수 있을 것이다. Fred는 멋진 이름이며 입력하기도 쉽다. 입력이 쉬운 변수명을 원한다면 asdf를 사용해 보기 바란다.
단일 문자 변수명
변수명을 a, b, c 등으로 정한다면 간단한 텍스트 편집기로 해당 인스턴스를 검색하는데 애를 먹게 된다. 뿐만 아니라 그 변수가 무엇에 쓰이는 것인지 추측할 수 없게 방지하는 역할도 한다. 포트란(FØRTRAN)에서는 오랫동안 I, j, k를 인덱스 변수로 사용해왔다. 혹시라도 이러한 훌륭한 전통을 조금이라도 깨뜨리려는(예를 들어, ii, jj, kk 등으로 이름을 변경하려는) 사람이 있는가? 스페인 종교재판에서 이교도에게 어떠한 형벌을 가했는지를 그에게 경고하자.
창의적 오타
어쩔 수 없이 뭔가를 설명하는 변수명이나 함수명을 사용해야 하는 상황이라면 오타라는 무기를 선택하자. 몇몇 함수명과 변수명에 오타를 내고 다른 곳에서는 오타를 사용하지 않는다면(예를 들어, SetPintleOpening과 SetPintalClosing처럼) grep이나 IDE 검색 기술을 효과적으로 무력화할 수 있다. 이 방법은 생각보다 놀라운 효과를 발휘한다. 각기 다른 theatres/theaters(둘 다 극장을 의미)에 tory나 tori같이 국제적인 취향도 추가해본다.
추상화하라
가능한 한 it, everything, data, handle, stuff, do, routine, perform, 숫자 등과 같이 추상적인 단어를 변수명이나 함수명에 많이 사용하자(좋은 예, routineX48, PerformDataFunction, DoIt, HandleStuff, do_args_method).
머.리.글.자.
머리글자로 코드를 간결하게 만든다. 진짜 사나이는 머리글자를 풀어 설명하지 않고 있는 그대로를 선천적(유전적)으로 이해한다.
진화한 유의어 사전
유의어 사전에서 되도록이면 많은 단어가 같은 동작(예를 들어, 뭔가를 보여준다는 의미를 가진 display, show, present 등과 같은)을 가리키도록 하는 것도 지루함을 달랠 좋은 방법 중 하나다. 실제 의미상 차이가 없는 단어라 할지라도 알 듯 말듯하게 모호한 힌트를 제공하는 것도 잊지 말자. 때로는 비슷한 두 함수가 완전 다른 동작을 하는 경우가 있다. 이러한 경우에는 두 함수를 같은 단어로 설명한다(예를 들면, "파일 기록", "종이에 잉크 칠하기", "화면에 보여주기"를 print라는 한 단어로 설명할 수 있다). 어떤 경우에도 명확한 어휘를 사용해 특수 프로젝트에 사용할 용어집을 만들어 달라는 요구에 굴복하지 말아야 한다. 이러한 요구에 굴복하는 행위는 정보 은닉(information hiding)이라는 구조화된 디자인 원칙을 위반하는 프로답지 못한 행동이다.
다른 언어의 복수형을 사용하라
VMS 스크립트는 "Vaxen(Vax 컴퓨터의 복수형)"에서 반환하는 다양한 "statii(status의 복수형)"를 추적한다. 에스페란토(현재는 거의 쓰이지 않는 인공어), Klington(스타 트렉에 등장하는 전사 종족의 언어), Hobbitese(소설에 등장하는 가상 종족 호빗의 언어) 등을 사용하면 보다 효율적이다. Pluraloj와 같이 단어 뒤에 oj를 추가해서 에스페란토 어를 모방할 수 있다. 이러한 에스페란토를 사랑하는 작은 노력이 세계 평화에 기여하는 것임을 기억하자.
새로운 개념의 낙타표기법(CapiTaliSaTion)
무작위로 단어의 중간 음절 첫 글자를 대문자로 표기하자. 예를 들면 ComputeRasterHistoGram()처럼 메소드 명을 정할 수 있다.
이름을 재사용하라
언어의 규칙이 허용하는 범위 내에서 클래스, 생성자, 메소드, 멤버 변수, 파라미터, 지역 변수에 같은 이름을 사용하자. 이에 안주하지 말고 더 나아가서 {} 블록 내에서 이미 사용되고 있는 지역 변수명을 재사용할 수 있는지 고민하자. 이렇게 함으로써 유지보수를 담당하는 프로그래머가 모든 인스턴스의 범위를 유심히 살펴보도록 만들 수 있다. 특히 자바 언어에서는 일반 메소드를 생성자처럼 보이게 할 수 있다.
강세가 있는 단어
변수명에 강세가 표시된 단어를 사용하자. 아래 코드를 살펴보면,
typedef struct { int i; } int;
두 번째 int에서 i 에 강세가 있다. 간단한 텍스트 편집기로는 미묘한 차이를 구별하는 것이 거의 불가능하다.
컴파일러의 이름 길이 제한을 악용하라
컴파일러가 인식할 수 있는 변수명의 길이는 정해져 있다. 만약 변수명의 8글자만을 인식할 수 있는 컴파일러가 있다면, var_unit_update()과 var_unit_setup()처럼 마지막 부분만 살짝 바꿔보자. 그럼 컴파일러는 두 이름을 동일한 var_unit으로 인식할 것이다.
밑줄(underscore)은 진정한 친구다
_와 __를 식별자로 사용하자.
언어를 혼용하라
두 언어(사람의 언어나 컴퓨터의 언어)를 무작위로 배치하자. 만약 상사가 자신의 언어를 사용할 것을 강요한다면 어떻게 할 것인가? 상사에게 나만의 언어를 사용해야 생각을 더 잘 정리할 수 있다고 설명하자. 신사적인 설명으로 해결되지 않는다면? 언어 차별 행위에 대해 이의를 제기하고, 당장 고용주를 고소를 할 수도 있으며 거액의 배상금을 내야 하는 상황에 처할 수 있다고 협박하자.
확장 아스키(Extended ASCII)
ß, Ð, n 등과 같은 확장 아스키 문자도 변수명에 사용할 수 있다는 사실을 잊지말자. 간단한 편집기에서는 복사/붙여넣기 말고는 확장 아스키 문자를 입력할 수 있는 방법이 없다.
다른 언어의 이름을 활용하자
외국어 사전은 다양한 변수명을 제공하는 마르지 않는 샘과 같다. 예를 들어, point 대신 독일어 punkt를 사용할 수 있다. 비록 우리가 독일어를 잘 알진 못하지만, 유지보수 코더로 하여금 의미를 해독하면서 다양한 문화를 경험할 수 있게 해줄 수 있다.
수학에서도 이름을 구할 수 있다
아래와 같이 수학적 기호를 나타내는 단어를 변수명으로 사용해보자.
openParen = (slash + asterix) / equals;
정말 멋진 이름
의미상으로 전혀 관계없는 이름을 변수명으로 사용해보라.
marypoppins = (superman + starship) / god;이 글을 읽는 사람은 자신도 모르게 단어의 뜻에 더 집중하게 되고, 실제 로직은 이해하기가 어려워진다.
이름을 변경하고 재사용하라
이름을 변경하고 재사용하는 기법은 Ada에서 특히 잘 먹힌다. Ada는 많은 표준 역컴파일 방지(obfuscation) 기법을 무력화시키는 언어다. 현재 사용하고 있는 모든 오브젝트와 패키지 이름을 처음 붙인 사람 대부분이 멍청이다. 언제까지 그들이 변하기를 기다릴 수 없으므로, 우리가 바뀌고 또 바꿔야 한다. Ada의 subtype과 renames를 이용해 우리만의 이름으로 개정하자. 방심하는 자들을 위한 함정으로, 예전 이름에 대한 래퍼런스 몇 개는 남겨두는 것이 효과적이다.
i가 필요할 때
다른 변수는 몰라도 절대로 i 를 가장 안쪽의 루프 변수로 사용하지 말라. 이외의 용도로는 i 를 자유롭게 사용할 수 있다. 특히, 정수가 아닌 변수에 사용할 때 더욱 효과적이다. 비슷한 방법으로 루프 인덱스로 n 을 사용할 수 있다.
규칙에 얽매이지 말지어다
썬 마이크로 시스템즈 스스로도 지키지 않는 선 자바 코딩 규칙(Sun Java Coding Conventions)은 가볍게 무시하자. 특수한 상황에서만 뜻이 미묘하게 달라지도록 이름을 정해보자. 어쩔 수 없이 낙타 표기 규칙을 따라야만 한다면 모호한 상황을 적극 활용해야 한다. 예를 들어, inputFilename와inputfileName을 혼용하는 것도 좋은 방법이다. 창의력을 발휘해서 이름을 복잡하게 지을 수 있는 자신만의 비법을 개발하자. 좋은 비법을 개발했는데도 따르지 않는 자가 있다면 바로 질책하자.
소문자 l과 숫자 1은 닮았다
Long 상수를 표현할 때 소문자 l을 사용해 보라. 예를 들어, 10l로 표기하면 10L이 아닌101로 착각하기 쉽다. uvw wW gq9 2z 5s il17|!j oO08 `'" ;,. m nn rn {[()]} 등의 문자를 명확하게 구분해주는 폰트를 멀리하자. 창의력을 발휘해보자.
전역으로 사용한 이름을 지역에 재사용하라
모듈 A에 전역 배열을 선언하고 같은 이름의 배열을 모듈 B의 헤더파일에 쥐도 새도 모르게 선언하자. 그러면 십중팔구 B에 선언한 배열을 전역 배열로 착각할 것이다. 물론 주석에 이와 같은 중복 선언이 있다는 사실을 알리는 행동은 삼가야 한다.
함수의 선언과 구현의 재활용
때로는 변수명을 정반대로 재활용해서 혼란을 야기하는 방법도 있다. 지역 변수 A, B와 지역 함수 foo, bar를 선언한다고 가정하자. 일반적으로 A는 foo의 매개변수로, B는 bar의 매개변수로 사용한다. 그러나 함수 선언을 실제 사용과 반대로 foo(B)와 bar(A)로 정의한다. 이렇게 해서 같은 변수명을 다른 용도로 사용하는 것처럼 만들 수 있다. 유지보수 프로그래머는 우리가 쳐놓은 혼란의 거미줄에서 빠져나가기 힘들어진다.
변수를 재사용하라
변수 존재 범위 규칙이 허용한다면 아무 관련 없는 기존의 변수명을 재사용해보라. 하나의 임시 변수를 전혀 관련이 없는 다양한 상황에 사용할 수 있다(변수를 재사용함으로써 스택 슬롯을 절약하는 것처럼 위장할 수 있다). 조금 더 사악한 방법을 원한다면 변수 자체의 의미를 변형하는 기법을 이용하라. 코드의 길이가 매우 긴 메소드의 가장 윗 부분에서 변수에 값을 할당한 다음 중간 어딘가에서 슬그머니 변수의 의미를 바꿀 수 있다(예를 들어, 0 기반 좌표를 1 기반 좌표로 바꾸는 등). 물론 이와 같은 변경을 문서화 해놓는 실수를 범하지 않아야 한다.
Cd wrttn wtht vwls s mch trsr
변수명이나 메소드명에 약어를 사용할 때에는 비록 이름이 길어질 수 있겠지만, 같은 단어에 다양한 변형을 더해 지루함을 없앨 수 있다. 이 기법은 문자열을 검색해서 우리 프로그램의 일부 기능을 이해해 보려는 게으름뱅이를 효과적으로 골탕먹일 수 있다. 철자를 어떻게 변형할 수 있는지 생각해 보라. 예를 들어, 국제적으로 사용하는 colour에 미국식 color 그리고 격식 없이 사용하는 kulerz 등 색을 가리킬 수 있는 단어를 다양하게 혼용할 수 있다. 이름을 생략하지 않으면 다양성을 상실한다. 결국 유지보수 프로그래머가 기억하기 쉬운 이름이 될 수 있다. 단어를 축약하는 방법은 다양하므로 한 단어를 같인 목적으로 사용하는 경우라도 다양하게 축약할 수 있다. 의도한 것은 아니지만 다양한 축약 표현을 사용하다보면 유지보수 프로그래머는 각각의 축약 단어가 서로 다른 변수라는 사실조차 눈치채지 못할 수 있다.
삼천포로 인도하는 이름
메소드의 이름이 의미하는 것보다 더 많은(혹은 더 적은) 동작을 수행하도록 프로그래밍하자. 간단한 예로 isValid(x)라는 메소드에 기능을 추가해 x값을 이진수로 변환하고 결과를 데이터베이스에 저장하도록 구현한다면 모두를 깜짝 놀랄 것이다.
m_
C++의 세계에서는 멤버 이름 앞에 "m_"을 붙이는 규약이 있다. 이는 메소드와 멤버를 구별하려고 만든 규약인데, 이 규약을 만든이는 메소드(method) 역시 "m"으로 시작한다는 사실을 잊은 듯 하다.
o_apple obj_apple
클래스의 인스턴스명을 "o"나 "obj"로 시작함으로써 우리가 크고 다형성을 갖춘 그림을 염두에 두고 있다는 사실을 보여주자.
헝가리 표기법
헝가리안 표기법은 소스 코드 판독을 어렵게 하는 핵폭탄급 기법 중 하나다. 헝가리안 표기법을 사용해보자! 소스코드는 방대하므로 헝가리안 표기법을 활용해 적절하게 코드를 오염시킨다면, 그 어떤 방법보다도 효율적으로 유지보수 엔지니어를 쓰러뜨릴 수 있다. 아래는 헝가리안 표기법의 본래 의도를 무력화하는 팁이다.
C++에서 "c"를 const에 사용하라(C++). "c"는 C++ 이외의 언어에서는 보통 변수가 상수임을 가리킨다.
다른 언어에서는 다른 의미로 해석되는 헝가리안 물혹(wart, 덧붙이는 음절이나 단어)을 찾고 사용하라. 예를 들어, C++ 코딩에서 모든 제어 형식에 "l_"과 "a_"와 같은 범위를 가리키는 접두어(파워빌더에 l은 지역을 a는 매개변수를 가리킨다)와 VB 스타일의 헝가리안 물혹을 사용하라. MFC 소스 코드에서 제어 형식에 헝가리안 물혹 표기법을 사용하지 않는 다는 사실을 마치 모르는 것처럼 행동하라.
공통적으로 자주 사용하는 변수는 되도록이면 추가 정보를 포함하지 말아야 한다는 헝가리안 원칙을 항상 위반하자. 위에서 설명한 기법들을 총 동원하고 각 클래스 형식은 커스텀 접두 물혹을 가지고 있다고 주장하므로 이를 달성할 수 있다. 물혹이 없는 것은 클래스임을 의미한다는 사실을 간파할 수 없게 해야 한다. 이는 정말 중요한 원칙이다. 이 원칙을 지키지 못하면 소스코드에 모음/자음 비율이 높아지면서 짧은 변수명이 범람하게 된다. 최악의 경우 소스코드 판독 방해 작전이 실패할 수 있고 자신도 모르는 새에 영어 표기법이 코드에 나타날 수 있다!
함수 파라미터와 여타 심볼은 이름을 통해 의미를 나타내야 한다는 헝가리안 개념을 노골적으로 위반하자. 그러나 헝가리안 형식 물혹 자체의 사용이 변수를 임시 변수로 보이게 할 수 있다.
의미상 전혀 연관이 없는 헝가리안 물혹 여러 개를 덧붙여 사용해보자. 실생활에서 활용된 예를 들면 "a_crszkvc30LastNameCol"같은 변수를 만들 수 있다. 유지보수 엔지니어 팀 전체가 이 변수명을 "이 변수는 const이고 레퍼런스 형식으로 함수 매개변수로 사용되는데 테이블의 기본 키 가운데 하나인 ‘LastName’이라는 이름의 Varchar[30] 형식의 데이터베이스 열에서 가져온 데이터를 담고 있다."라고 해독하는데 3일이 걸렸다. "모든 변수는 public이어야 한다"라는 규칙을 이 기법에 접목하면 수천 라인의 코드를 대체할 수 있는 막강한 파워를 발휘할 수 있다!
사람의 뇌는 동시에 오직 7 개의 정보를 유지할 수 있다는 원칙을 마음껏 활용하자. 위 규칙을 따른다는 것은 다음과 같은 코드를 작성한다는 것을 의미한다.
- 하나의 할당문에 14개의 형식과 이름 정보를 사용한다.
- 하나의 함수가 3개의 매개변수를 전달하고 29 개의 형식과 이름 정보를 가진 결과값을 할당한다.
- 적당히 복잡한 중첩 구조를 이용하면 단기 기억의 한계를 가볍게 초과할 수 있다. 특히 유지보수 프로그래머가 블록의 시작과 끝을 한눈에 확인할 수 없는 경우에 효과가 커진다.
- 유지보수 프로그래머가 각 블록을 한 화면에 확인하기 어렵게 만들 수 있다면 중첩 구조체로도 단기 기억 메모리 한계를 간단히 초과할 수 있다.
헝가리안 표기법의 변형
헝가리안 표기법을 활용한 또 다른 술책으로 "변수명은 그대로 사용하되 변수 형식을 바꾸는" 방법이 있다. 이 방법은 윈도 응용 프로그램이 Win16 WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam)에서 to Win32 WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam)로 변경되는 경우와 같은 상황에서 어김없이 등장한다. 여기서 w는 words임을 가리키는 듯 하지만 실제로는 long을 가리킨다. Win64로 응용 프로그램을 변경하는 경우 이 사실이 더욱 명확해진다. Win64에서는 파라미터가 64비트이지만 기존의 "w"와 "I" 접두어는 변하지 않는다.
줄이고, 재사용하고, 재활용하라
콜백(callback)에 사용할 데이터를 저장할 구조체를 정의해야 한다면, 그 구조체를 PRIVDATA라고 부르자. 모든 모듈은 자신만의 PRIVDATA를 정의할 수 있다. 이 구조체로 VC++의 디버거를 교란시킬 수 있다. 변수 watch 윈도우에 PRIVDATA 변수가 있는 상태에서 해당 변수를 펼치려고 하면 디버거는 어느 PRIVDATA를 의미하는 것인지 결정할 수 없어 아무것이나 선택한다.
쉽게 찾지 못하게 숨겨라
16진수 값 $0204FB를 할당할 상수 변수명으로 blue 대신 LancelotsFavouriteColour와 같은 이름을 사용하라. 화면에는 완전한 파랑색이 나타나겠지만, 유지보수 프로그래머는 0204FB값을 판독(아마 그래픽 도구를 이용해서)해야 의미를 파악할 수 있을 것이다. 몬티 파이썬의 성배(Monty Python and the Holy Grail)라는 1975년 영국 영화를 좋아하는 광팬이라면 랜슬롯(Lancelot)이 좋아하는 색이 파랑색이라는 사실쯤은 금방 알아차릴 수도 있을 것이다. 몬티 파이썬의 성배 영화 전체 내용을 기억하지 못하는 유지보수 프로그래머가 있다면 프로그래머로써 자질이 없는 분이라고 생각할 수 밖에 없다.
다음회 계속...
본 블로그는 페이스북 댓글을 지원합니다.
