유지보수하기 어렵게 코딩하는 방법

유지보수하기 어렵게 코딩하는 방법

• 부제 - 평생 개발자로 먹고 살 수 있다

저자의 말

• 진심을 다해 이 책에서 제시한 규칙을 지켜 코딩한다면 본인 외에는 누구도 그 코드를 유지보수 할 수 없게 된다.
• 즉, 평생 직장을 보장받게 될 것이다.
• 혹은 모든 규칙을 진심으로 따른다면 본인조차도 자신이 만든 코드를 유지보수 할 수 없는 날이 올 것이다!

독자(나)의 말

- 양도 그리 많지 않았지만 꽤 재밌게 스윽 하루만에 다 봤다. 

- 이 중에는 공감이 되는 부분도 많이 있었지만 따라하고 싶은 것도 몇 가지 있었다 ㅋㅋㅋㅋㅋㅋㅋ 

- 어떤 면에서는 참 이 글을 쓴 사람이 천재다라고 생각도 들었는데 그런 짓(!)을 내가 이미 하고 있었던 걸지도 모르겠다 ㅋㅋㅋ

단일 문자 변수명

• i,j,k를 인덱스 변수로 많이 써왔는데 ii, jj, kk는 어떤가 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

창의적 오타

• 어쩔 수 없이 뭔가를 설명하는 변수명이나 함수명을 사용해야 하는 상황이라면 오타라는 무기를 선택하자
• setPintleOpening 과 setPintalClosing
• tory 와 tori
• 이러면 grep이나 IDE 검색 기술을 효과적으로 무력화시킬 수 있다.

추상화하라

• 가능한 it, everything, data, handle, do, perform 같은 추상적인 단어를 변수명이나 함수명에 많이 사용하자

새로운 개념의 낙타표기법

• 무작위로 단어의 중간 음절 첫 글자를 대문자로 표기하자. 
• ex) ComputeRasterHistoGram()

밑줄은 진정한 친구다

• _와 __를 식별자로 사용하자

다른 언어의 이름을 활용하자

• point 대신 독일어 punkt로 쓰자
• 유지보수 코더로 하여금 의미를 해독하면서 다양한 문화를 경험할 수 있게 해줄 수 있다.

정말 멋진 이름

• 의미상으로 전혀 관계없는 이름을 변수명으로 사용하자

소문자 l과 숫자 1은 닮았다.

• 10ㅣO1l1l0O1ll1l1
• 이 차이를 명확하게 구분해주는 글꼴을 멀리하자

전역으로 사용한 이름을 지역에 재사용하라

변수를 재사용하라.

약어

• cd mch wrttn

삼천포로 인도하는 이름

• 메소드의 이름이 의미하는 것보다 더 많은(혹은 더 적은) 동작을 수행하도록 프로그래밍하자
• isValid(x)라는 메소드에 기능을 추가해 x 값을 이진수로 변환하고 결과를 DB에 저장하도록 구현한다면 아주 재밌을 것이다.

쉽게 찾지 못하게 숨겨라

• 16진수 값 $0204FB를 할당할 상수 변수명으로 blue 대신 LancelotsFavouriteColour와 같은 이름을 사용하자
• 영화 주인공인 랜슬롯이 좋아하는 색을 모르는 유지보수 프로그래머가 있다면 프로그래머로서 자질이 없는 분이라고 생각할 수 밖에 없다.

주석으로 위장한 코드와 코드로 위장한 주석

• total += array[j+0]; /* 속도 향상을 위해
• total += array[j+1]; * 루프의 코드를 길게
• total += array[j+2]; * 펼쳐놓았다.
• total += array[j+3]; */
• 이런 경우는 아주 재밌다 ㅋㅋㅋㅋ 다른 색으로 표시되지 않으면 정말 찾아내기 힘들다

코드에 사용한 이름은 화면 표시 이름과 달라야 한다.

• UI에는 zip, 코드에는 exe로 하자

길고 비슷한 변수명

• parseInt, parselnt, HashTable, Hashtable

---

4 문서화

컴퓨터는 주석과 문서화 부분은 무시한다.

따라서 온 힘을 기울여 주석과 문서화를 활용한다면 불쌍한 유지보수 프로그래머를 좌절시킬 수 있을 것이다.

주석에 거짓말을 추가하라

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

명백한 사실을 문서화하라.

• 간단한 코드에 주석을 달고 어려운 부분은 절대 문서화 하지 말자

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

문제점

• 코드의 문제점을 문서화하지 않는다.
• 버그가 있을 수 있다는 사실을 발견했으면 혼자만의 비밀로 간직한다.
• 코드를 어떻게 재조직하거나 재작성해야 할지 아이디어가 떠올랐을지라도 문서로 남겨놓지 않는다.

---

5 프로그램 디자인

자바형변환

• 자바의 형변환 스킴은 신의 귀중한 선물이다.
• 아무 거리낌없이 남용할 수 있어야 한다.

Assert를 멀리하라

• 3일짜리 버그 축제를 10분짜리로 만들어 버릴 수 있으므로 피해야 한다.

캡슐화를 멀리하라

혼합과 매치

• 가능하면 accessor 메소드와 public 변수를 함께 사용한다.
• 누가 변수 값을 변경하는지 알아내려고 유지보수 프로그래머를 좌절시킬 수 있다는 장점도 제공

카마수트라(왜 이 단어가 쓰였는지는 잘 모르겠다. 그냥 책에 나와있으므로)

• 같은 메소드에 수십 개 이상의 오버로드를 이용한 변형을 생성해 약간만 다른 기능을 하게 만든다.
• drop(int a), drop(int a, int b), drop(string a, int a), drop(bool a, bool b int c), drop(char c, int b, string c, int d, bool e = false) .....

static이 좋다

• 가능하다면 변수를 static으로 만들자

아무리 강조해도 지나치지 않을 그대 이름은 전역!

• 우리가 전역 변수를 사용하는 것을 원치 않았다면 신은 전역 변수라는 것을 창조하지 않았을 것이다.
• 따라서 가능한 전역 변수를 많이 사용하여 신을 실망시키지 말아야 한다.

중첩된 switch

세미콜론

• 문법적으로 허용된 곳이라면 어디에든 세미콜론을 사용하라 
• if(a);
• else;
•      {
•      int d;
•      d = c;
•      }
• ;

중첩

• 가능한 한 깊이 중첩하라
• 게다가 한 줄 이상의 코드로 확장할 수 있다면 금상첨화다
• if(...){ if(...){ if(...){if (... ){if(...){}else if(...)}else if(...)...............

긴 줄

• 가능하면 많은 내용을 한 줄에 담으려 노력하라.
• 줄바꿈 문자나 공백 문자를 제거함으로써 소스파일 크기를 줄이는 효과를 제공한다.
• 좋은 프로그래머는 몇몇 편집기의 한 줄에 들어갈 수 있는 문자 크기의 한계인 255문자까지 활용하기도 한다.
• 글자 크기를 6으로 맞추었을 때 글자를 읽지 못한다면 스크롤해서 읽도록 길게 코딩하는 것이 정석이다.

스레드에 떠넘기라

• 제목 그대로 행동하라

*++b ? (*++b + *(b-1)) 0

변기 배관

• 어떤 경우에도 함수나 프로시저가 한 화면에 모두 보이도록 하지 말아야 한다.
• 간단한 루틴에는 이런식으로
• /* 프로시저 이름:
• /*
• /* 원래 프로시저 이름:
• /*
• /* 저자 :
• /*
• /* 생성일:
• ...

---

07 테스트

프로그램에 버그를 남겨둠으로써 유지보수 프로그래머에게도 재미있는 일거리를 제공해야 한다.

잘 만든 버그라면 어디서 어떻게 발생했는지에 관한 단서를 남기지 않는다.

버그를 남겨두는 가장 게으른 방법으로는 우리 코드를 절대 테스트하지 않는 방법도 있다.

절대 테스트하지 마라

세상이 무너져도 성능 테스트를 하지 않는다.

절대 테스트 케이스를 만들지 않는다.

• 코드 커버리지나 패스 커버리지 테스트를 절대 수행하지 말자.
• 자동화 테스트는 겁쟁이나 하는 것이다.

---

08 언어 선택

최첨단 언어에 의존하는 것은 좋은 프로그래머 답지 못한 행동이다. 

우리가 사용할 수 있는 가장 오래된 언어 사용을 고집하자.

가능하다면 8진법 기계어, 안 된다면 어셈블러, 안 되면 포트란이나 코볼, 안 되면 C, 안 되면 베이직, 안 되면 C++로 시도하자.

프토란으로 코드를 작성하면 유지보수할 수 있는 확률은 0이다 ㅋㅋㅋㅋㅋㅋㅋㅋ

---

09 발상의 전환

그 입 다물라

• 심각한 일이 벌어질 날이 다가오는 걸 알았더라도 실제 문제가 발생할 때까지는 공개적 토론을 삼가야 한다.

직접 만들어라

• 표준라이브러리는 무시하고 자신만의 라이브러리를 만들어보자. 이것이 우리의 이력서를 빛낼 것이다.

---

11 잡다한 기법

재컴파일하지 마라

디버거 차단

• 줄을 길게 만들어서 디버거를 이용해서 한 줄씩 우리 코드를 이해하려는 사람을 좌절시킬 수 있다.
• 특히 브레이크 포인트를 잡기 어렵게 if와 then을 한 줄에 모두 사용하면 더욱 효과적이다.
• 그러면 분기문이 어느 문장을 수행하는 것인지 구별하기 어려워진다.

변화, 변화, 변화하라

• 버전마다 더 많은 변화를 줄 수록 좋다.

한 개의 망치만 사용한다

• 자신이 잘 아는 도구를 사용해 가볍게 여행하자. 망치 하나만 있으면 모든 문제는 못에 불과하다.

표준을 무시하라

• 가능하면 프로젝트를 진행하는 언어와 환경에서 수 천명이 사용하는 코딩 표준을 무시해야한다.

일반적인 true, false 규칙을 뒤집어라

• 이게 보기보다는 파급효과가 크다 
• #define TRUE 0
• #define FALSE 1
• if (var == TRUE) 
• if (var != FALSE)

컴파일러 경고

• 컴파일러 경고를 모두 수정하지 말고 남겨두는 게 좋다.
• Make 파일에 접두어 "-"를 사용해서 컴파일 에러로 make가 실패하는 걸 방지할 수도 있다.

버그 수정과 업그레이드를 혼합하라

• 절대 "버그만 수정한" 버전을 릴리즈하지 말아라.
• 버그를 수정했으면 DB 형식도 바꾸고, 복잡한 사용자 인터페이스도 바꾸고, 관리자 인터페이스도 바꾸자
• 이렇게 하면 사람들은 그냥 버그에 익숙해지려 하고 결국 버그를 기능이라 부르기 시작할 것이다.
• 이런 방식으로 유지보수 작업을 줄일 수 있고, 고객으로부터 얻는 수익도 늘어난다.

동기화 코드를 마구 뿌려대라.

실생활 예제

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;

}

1. Realocate 철자
2. 아무런 이유없이 입력 버퍼를 임시 복사본을 만든다.
3. 이유 없이 형변환
4. temp 해제
5. os, ns는 아마도 old size, new size 인듯
6. 표준라이브러리에 이미 있는 간단한 함수는 다시 만든다.
7. ...

사용하지 않은 변수 에러를 고치는 방법

• 컴파일러에서 "사용하지 않은 지역 변수" 경고가 난다고 해서 그 변수를 꼭 없앨 필요는 없다. 나같으면 ...
• i = i;

중요한 것은 크기

• 함수가 크면 클수록 좋다는 것은 두말하면 잔소리인 진리다.
• 물론 jump와 GOTO도 많을수록 좋다.

마지막으로, 이 글은 농담일 뿐이다! 

혹시라도 이 글의 내용을 있는 그대로 받아들인 이가 있다면 정중히 사과한다.

내가 유지보수할 수 있는 코드를 작성하는 방법에 관해 지껄일 때면 사람들은 별로 관심을 가지지 않았다.

어느날 일을 그르치는 얼간이 같은 행동을 얘기해야 사람들이 더 반응을 보인다는 사실을 알게 됐다.

유지보수 할 수 없는 디자인 패턴을 확인하므로 더 효과적인 악의적인 혹은 부지불식간에 일어나는 나쁜 일을 예방할 수 있다.