아래글에 이어서 기재한다.


내가 머리 쥐어 뜯어가며 좆나게 만들었는데 남들이 쉽게 읽어서 홀라당 먹어버리면 얼마나 빡치겠는가?


유지보수를 "너"만 할 수 있어야 오래가는 개발자(?)가 될 수 있다.


몇가지 팁을 알려주고자 한다.

-----------------------------------------------------------------------------------

키워드를 위장한 이름

문서화 할 때에는 “file “과 같이 파일명을 표시해야 하고 Charlie.dat” 또는 “Frodo.txt”처럼 파일명을 명백히 표시

하지 말아야 한다. 되도록이면 가능한 한 예약어처럼 보이는 이름을 사용하는 것이 좋다. 예를 들어, “bank”, “blank”, 

“class”, “const”, “constant”, “input”, “key”, “keyword”, “kind”, “output”, “parameter” 

“parm”, “system”, “type”, “value”, “var” and “variable”등을 매개변수나 변수명으로 사용해야 한다. 실

제 예약어를 임의적으로 사용하면 명령어 프로세서나 컴파일러가 처리를 거부할 수 있다. 이를 잘 활용하면 사용자는 우리가 

만든 임의의 이름과 예약어를 혼동하게 만들 수 있다. 누군가 딴지를 걸면, 사용자가 각 변수의 이해를 적절히 돕기 위해 사

용한 것이라고 발뺌하면 그만이다.


동의어로 인스턴스 숨기기

유지보수 프로그래머가 뭔가를 수정하고 그로 인해 발생할 수 있는 부수효과를 확인할 때 일반적으로 프로그램 전체에서 사

용된 변수명을 검색할 것이다. 동의어 사용이라는 간단한 방법으로 이러한 유지보수 프로그래머의 시도를 좌절시킬 수 있다.

#define xxx global_var // in file std.h 

#define xy_z xxx // in file ..\other\substd.h 

#define local_var xy_z // in file ..\codestd\inst.h 

위 정의를 서로 다른 include 파일에 흩어놓아야 한다. 특히 include 파일이 서로 다른 디렉터리에 위치한 경우 효과적이다. 

가능한 모든 범위에서 이름을 재사용하는 기법도 있다. 컴파일러는 정확하게 모든 이름을 구별할 수 있겠지만, 단세포적인 

텍스트 검색기로는 이름을 구별하기 어려울 것이다. 불행하게도 SCID(Source Code in Database)가 점점 발전하면서 편집

기가 컴파일러처럼 범위 규칙을 이해하게 되면 간단한 기법은 더 이상 사용할 수 없게 될 것이다.


주석에 거짓말을 추가하라

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


명백한 사실을 문서화하라

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

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


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

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

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


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

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

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

는 수정을 할 수 있을 것이다


캡슐화를 멀리하라

효율성 측면을 고려할 때 캡슐화를 멀리해야 한다. 메소드 호출자는 메소드가 어떻게 동작하는지를 알 권리가 있다.


복사하고 수정하라

효율성이라는 명목으로 잘라내기/붙이기/복사하기/수정하기를 남발하자. 이 방식은 작은 재사용 가능한 모듈 여럿을 사용

하는 것보다 실행 속도가 빠르다는 장점이 있다. 특히 이 방식은 우리가 작성하는 코드 라인 수를 업무 진행 척도로 여기는 

곳에서 일할 때 유용하다.


정적 배열을 사용하라

라이브러리의 모듈에 이미지를 저장할 배열이 필요한 경우에는 정적 배열을 선언해야 한다. 아무도 512 x 512 크기 이상의 

이미지를 사용하지 않을 것이므로 크기가 고정된 배열도 좋다. 정확성을 높일 수 있도록 double 배열을 사용하는 것도 바람

직하다. 이렇게 하면, 2 메가 크기의 정적 배열을 효과적으로 숨길 수 있다. 클라이언트는 우리가 만든 루틴을 한번도 수행

하지 않았음에도 미친 것처럼 허우적대고 프로그램은 결국 클라이언트의 메모리를 초과할 것이다.


삼차원 배열을 사용하라

삼차원 배열을 적극 사용하자. arrayA의 행 데이터를 arrayB의 열에 채우기와 같이 배열간의 데이터를 이동할 때는 복잡

한 방법을 사용할수록 좋다. 특별한 이유 없이 오프셋을 0이 아닌 1로 사용한다면 유지보수 프로그래머를 불안하게 만들 수 

있다.


이것도 길어서 여기까지만 쓰겠다

깊숙히 새겨 보길~