Top 34 유지 보수 하기 어렵게 코딩 하는 방법 Trust The Answer

유지보수하기 어렵게 코딩하는 방법 : 네이버 블로그

• Article author: m.blog.naver.com
• Reviews from users: 23392 Ratings
• Top rated: 4.4
• Lowest rated: 1
• Summary of article content: Articles about 유지보수하기 어렵게 코딩하는 방법 : 네이버 블로그 유지보수하기 어렵게 코딩하는 방법: 평생 개발자로 먹고 살 수 있다. 작가: 로에디 그린; 출판: 한빛미디어(주); 발매: 2012.07.16. 평점. …
• Most searched keywords: Whether you are looking for 유지보수하기 어렵게 코딩하는 방법 : 네이버 블로그 유지보수하기 어렵게 코딩하는 방법: 평생 개발자로 먹고 살 수 있다. 작가: 로에디 그린; 출판: 한빛미디어(주); 발매: 2012.07.16. 평점.
• Table of Contents:

카테고리 이동

Stock Raiders

이 블로그 
독서노트
 카테고리 글

카테고리

이 블로그 
독서노트
 카테고리 글

Read More

See more articles in the same category here: https://chewathai27.com/to/blog.

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

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

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

저자의 말

진심을 다해 이 책에서 제시한 규칙을 지켜 코딩한다면 본인 외에는 누구도 그 코드를 유지보수 할 수 없게 된다.

즉, 평생 직장을 보장받게 될 것이다.

혹은 모든 규칙을 진심으로 따른다면 본인조차도 자신이 만든 코드를 유지보수 할 수 없는 날이 올 것이다!

독자(나)의 말

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

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

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

단일 문자 변수명

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;

}

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

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

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

i = i;

중요한 것은 크기

함수가 크면 클수록 좋다는 것은 두말하면 잔소리인 진리다.

물론 jump와 GOTO도 많을수록 좋다.

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

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

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

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

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

유지보수하기 어렵게 코딩하는 방법: 평생 개발자로 먹고 살 수 있다

책 제목을 보시고 무슨 생각이 드시나요?

개발자 분들은 조금 의아해 하실지도 모르겠습니다.

유지보수를 어렵게 코딩한다? 유지보수를 쉽게 코딩한다가 아니고??

네.. 맞습니다. 말그대로 유지보수 어렵게 코딩하는 방법을 알려주는 책입니다.

그럼 왜!! 왜 그런걸 알려주는 건데!!

-평생 개발자로 먹고 살 수 있다- 라는 부제가 달려있는 걸 보니.. 아마 코딩 어렵게 해서 남들이 알아보지 못하게 하여 자기의 몸값을 올리는 방법을 알려주려나 봅니다…ㅡ.ㅡ;; (네 맞습니다.!!!)

일단 개발자 분들은 재미로라도 한 번 읽어보시기를 추천합니다. (책 내용이 많은 것도 아니고, 무료라 구입 비용도 없습니다. 포스팅 맨 아래에 보시면 책을 다운로드 받으실 수 있는 링크를 걸어두었습니다.)

책 내용도 인정사정 없습니다.ㅎㅎ

이 책은 다른 설명을 드리는 것보다는 보면서 배꼽잡게 만든 내용들 일부를 추려서 올려보도록 하겠습니다.^^ 재미있는 글들이 훨씬 더 많습니다. ㅎㅎㅎ

아래는 실제 책 내용을 발췌한 것입니다. (글 뒤에 짧막한 글 또는 ㅡ.ㅡ; ㅋㅋㅋㅋ 이런 표현은 제가 붙인 것입니다. ㅎㅎ)

… 하나의 임시 변수를 전혀 관련이 없는 다양한 상황에서 사용할 수 있다(변수를 재사용함으로써 스택 슬롯을 절약하는 것처럼 위장할 수 있다.) … ㅡ.ㅡ;

삼천포로 인도하는 이름

메소드의 이름을 의미하는 것보다 더 많은(혹은 더 적은) 동작을 수행하도록 프로그래밍하자. 예로 isValid(x)라는 메소드에 기능을 추가해 x값을 이진수로 변환하고 결과를 데이터베이스에 저장하도록 구현한다면 모두가 깜짝 놀랄 것이다. … ㅡ.ㅡ;

쉽게 찾지 못하게 숨겨라

16진수 값 $0204FB를 할당할 상수 변수명으로 blue 대신 LancelotsFavouriteColour와 같은 이름을 사용하라. 화면에는 완전한 파랑색이 나타나겠지만, 유지보수 프로그래머는 0204FB값을 판독(아마 그래픽 도구를 이용해서)해야 의미를 파악할 수 있을 것이다. 몬티 파이썬의 성배Monty Python and the Holy Grail라는 1975년 영국 영화를 좋아하는 광팬이라면 랜슬롯Lancelot이 좋아하는 색이 파랑색이라는 사

실쯤은 금방 알아차릴 수도 있을 것이다. 몬티 파이썬의 성배 영화 전체 내용을 기억하지 못하는 유지보수 프로그래머가 있다면 프로그래머로서 자질이 없는 분이라고 생각할 수 밖에 없다. ㅋㅋㅋㅋㅋ

길고 비슷한 변수명

… 따라서 swimmer와 쉽게 구별하기 어려운 swirnrner도 좋은 변수명이다. … ????

문제점

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

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

외부 회사와 유지보수 계약을 체결할 수 없도록 다른 소프트웨어 선도 업체를 폄하하는 글을 추가한다. 특히 현재 회사와 계약할 수 있는 가능성이 있는 회사를 공격할수록 좋다. 예를 들면, 다음과 같다.

/* 내부 루프 최적화 Software Services Inc.,의 굼뱅이들은 아래와 같은 코드를 꿈에도 몰랐겠지. 그 녀석들은 아마 답답한 의 기능을 이용해서 50배나 느리고 메모리도 많이 사용했을 꺼야. */ 으아아아아~~

검증을 멀리하라

입력 데이터에 대한 어떤 종류의 불일치 검사나 정확성 검사를 수행하지 않는다. 즉, 우리는 회사 장비를 온전히 신뢰하고 있으며 모든 프로젝트 파트너와 시스템 운영자를 신뢰하는 완벽한 팀원임을 보여줄 수 있다. 입력 데이터가 이상하거나 문제가 있는 듯 보이더라도 항상 합리적인 값을 반환하기 위해 노력해야 한다. -_-;;;

테마와 변형

하나의 메소드에 파라미터를 사용하기보다는 되도록이면 여러 메소드를 만드는 것이 좋다. 예를 들어, 왼쪽, 오른쪽, 가운데 정렬을 의미하는 상수를 파라미터로 넘겨줄 수 있는 setAlignment(int alignment)보다는 setLeftAlignment, setRightAlignment, setCenterAlignment와 같이 세 개의 메소드를 정의하는 것이 바람직하다. …

퉁퉁 부은 클래스

중요하지 않고 잘 알려지지 않은 메소드와 속성을 모든 클래스에 포함시킴으로써 외부에 둔감한 클래스를 만들 수 있다. 일례로, 천체 기하학적 궤도를 정의하는 클래스에 해수면 조류 스케쥴과 크레인Crane 날씨 모델을 구성하는 속성을 포함할 수 있다. 이와 같은 기법으로 클래스에 수많은 기능을 정의할 수 있을 뿐만 아니라 시스템에서 필요한 부분을 검색하는 작업을 서울에서 김서방 찾기처럼 힘들게 만들 수 있다. … (김서방 찾아 봅시다..;;;)

읽을 수 없는 C

인터넷의 읽을 수 없는 C 경연대회에 참석하고 스승님의 책상다리 근처에 앉아 경청하라 … (실제 있는 대회야???!!!)

긴 줄

가능하면 많은 내용을 한 줄에 담으려 노력하라. 이 기법은 임시 변수를 줄이고, 줄바꿈 문자나 공백 문자를 제거함으로써 소스파일 크기를 줄이는 효과를 제공한다. … ㅡ,.ㅡ;;

언제 예외를 사용해야 하는가?

예외가 발생하지 않는 상황에서만 예외를 사용하라. … ㅋㅋㅋ

테스트

프로그램에 버그를 남겨둠으로써 유지보수 프로그래머에게도 재미있는 일거리를 제공해야 한다. 잘 만든 버그라면 어디서 어떻게 발생했는지에 관한 단서를 남기지 않는다. … (알았다..)

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

프로그램이 좀 느리다고? 고객에게 더 빠른 컴퓨터를 사라고 말하자. … 게다가 고객사에 성능 문제가 불쑥 나타난다는 것은 이국적인 곳으로 공짜 여행을 할 수 있는 기회일 수 있다. 정말로 우리가 해야 할 일은 여권을 항상 가까이에 소지하면서 상황을 예의주시하는 것이다. (그렇군… 좋은 내용이다..;;;)

디버거 차단

… 특히 브레이크 포인트를 잡기 어렵게 if와 then을 한 줄에 모두 사용하면 더욱 효과적이다. … (대단한 방법이다!!!)

서드파티 라이브러리

프로젝트에 막강한 서드파티 라이브러리를 포함하고는 사용하지 않는다. 추가하고 사용하진 않았지만, 우리의 이력서 “기타 도구” 부분에 사용하지 않았던 도구 이름을 추가할 수 있다. … ……;;

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

Created: June 6, 2021 1:58 AM

Ch02. 이름 짓기

단일 문자 변수명

오랫동안 i , j , k 를 인덱스 변수로 사용해왔다. 훌륭한 전통을 깨자.

추상화하라

it , everything , data , handle , stuff , do , routine , perform 숫자 등과 같은 추상적인 단어를 변수명이나 함수명에 많이 사용하자.

진화한 유의어 사전

유의어 사전에서 되도록이면 많은 단어가 같은동작( display , show , present 등)을 가리키도록 하는 것도 지루함을 달랠 좋은 방법 중 하나다.

변수명의 길이

컴파일러가 인식할 수 있는 변수명의 길이는 정해져 있다. 만약 변수명의 8글자만을 인식할 수 있는 컴파일러가 있다면, var_unit_update() 과 var_unit_setup() 처럼 마지막 부분만 살짝 바꿔보자.

i가 필요할 때

다른 변수는 몰라도 절대로 i 를 가장 안쪽의 루프 변수로 사용하지 말라.

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

long 상수를 표현할 대 소문자 l 을 사용해 보라.

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

Ch03. 위장술

금지된 지역변수를 감추는 방법

전역변수는 악과 같은 존재이므로 전역적으로 사용할 모든 데이터를 저장할 구조체를 정의하고 EverythingYouEv-erNeed 와 같이 똘똘한 이름을 붙여준다.

길고 비슷한 변수명

변수명이나 클래스명은 되도록이면 길게 만들고 두개 이상의 이름이 필요할 경우 한 글자만 바꿔놓거나 대소문자만 다르게 한다. 변수명 swimmer 와 swimner 는 좋은 예다. 뿐만 아니라 대분의 폰트에서 rn 은 m 처럼 보이는 경우가 많기에 swimmer 와 쉽게 구별하기 어려운 swirnrner 도 좋은 변수명이다.

Ch04. 문서화

주석에 거짓말을 추가하라

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

명백한 사실을 문서화하라

코드에 /* add 1 to i*/ 와 같은 양념을 추가하라.

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

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

변수 문서화

변수 선언에는 절대로 주석을 달지 않는다. 변수를 어떻게 사용해야 하고, 경계 값은 무엇이며, 사용할 수 있는 값은 무엇이고, 함축된/표시된 십진수 점, 측정단위, 표현형식, 데이터 입력규칙(전체 값을 채워야 하는지, 반드시 입력해야 하는지와 같은), 값을 신회할 수 있는 조건 등과 같은 정보는 코드를 통해 충분히 얻을 수 있다.

유지보수가 쉬운 코드 작성의 핵심 요소는 응용프로그램의 각 요소를 한 곳에 정의하는 것이다. 바꾸어서 생각해보면 우리가 수정해야할 코드가 한 곳에 모여있음을 의미한다. 이렇게 하면 수정을 하더라도 전체 프로그램 수행에 영향을 최소화할 수 있다. 즉, 유지보수가 어려운 코드를 만들려면 요소를 반복적으로 가능한 여러장소에 기술해야 한다.

Ch05. 프로그램 디자인

정적 배열을 사용하라

라이브러리 모듈에 이미지를 저장할 배열이 필요한 경우에는 정적배열을 선언해야 한다. 아무도 512 x 512 크기 이상의 이미지를 사용하지 않을 것이므로 크기가 조정된 배열도 좋다. 클라이언트는 우리가 만든 루틴을 한번도 수행하지 않았음에도 미친 것처럼 허우적 대고 프로그램은 결국 클라이언트의 메모리를 초과할 것이다.

삼차원 배열을 사용하라

삼차원 배열을 적극 사용하자. 배열 간에 데이터를 이동할 때는 복잡한 방법을 사용할 수록 좋다. 특별한 이유 없이 오프셋을 0이 아닌 1로 사용한다면 유지보수 프로그래머를 불안하게 만들 수 있다.

치환으로 당황시키기

drawRectangle(height, width) 라는 메소드가 있다면 다른 부분은 건드리지 말고 파라미터 순서만 drawRectangle(width, height) 처럼 역순으로 바꿔보자. 유지보수 프로그래머는 그런 변경이 일어났는지 쉽게 구별하기가 어려울 것이다.

테마와 변형

공통 로직을 복제해서 동기화를 어렵게 만들면 효과가 커진다. 예를들어, 왼쪽, 오른쪽, 가운데 정렬을 의미하는 상수를 파라미터로 넘겨줄 수 있는 setAlignment(int alignment) 보다는 setLeftAlighment , setRightAlignment , setCenterAlignment 와 같이 세 개의 메소드를 정의하는 것이 바람직하다.

static이 좋다.

가능하다면 변수를 static 으로 만들자. 프로젝트의 다른 코더가 이에 대해 불평한다면 이 방법 덕분에 실행속도가 빨라졌음을 알려주자.

final이 주는 즐거움

모든 최종 클래스를 final로 정의하라. 이렇게 프로젝트를 마무리할 수 있다. 즉 아무도 우리가 만든 클래스를 확장해 작업을 개선시킬 수 없다. 프로젝트의 다른 코더가 불편한다면 언제나처럼 이 기법으로 인해 얻고 있는 속도 향상에 대해 얘기해주면 된다.

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

가능한 전역변수를 많이 사용하여 신을 실망시키지 말아야 한다. 특별한 이유가 없더라도 각 함수에서는 최소한 두개 이상의 전역변수를 사용해야 한다. 전역변수를 사용하면 함수에서 매개변수를 지정하는 일을 생략할 수 있는 장점도 있다. 이를 적극 활용하자.

Ch06. 코드 혼잡화

암시적 변환을 악용하라

프로그래밍 언어에서 제공하는 모든 미묘한 암시적 변환 규칙을 기억한 다음 그들을 최대한 활용하자. 잘 정의한 함수 덕분에 우리 코드는 한결 단순해진다. 우리가 만든 코드를 유지보수할 프로그래머는 암시적 데이터형 변환 전체 장을 읽어야한 하는 기회를 준것에 대해 우리에게 감사할 것이다.

숫자 기호

상수를 이해하고 대체하기 어렵게 하려면 100/2 보다는 50 , 100 – 1 보다는 99 와 같이 표기하는 것이 좋다. a > 100 보다는 a == 101 을 사용하고 a >= 100 보다는 a > 99 를 사용하면 100 이라는 숫자가 사용되지 않은것 처럼 위장할 수 있다.

긴 줄

가능하면 많은 내용을 한 줄에 담으려 노력하라. 이 기법은 임시 변수를 줄이고, 줄바꿈 문자나 공백문자를 제거함으로써 소스파일 크기를 줄이는 효과를 제공한다.

변호사 코드

예를 들어 a = a++;, f(a++, a++); 과 같이 논쟁이 벌어지는 코드를 우리 프로그램에 자유롭게 사용하자.

Ch11. 잡다한 기법

특별한 기술은 없다

큰 기술이 있어야 유지보수할 수 없는 코드를 작성할 수 있는 것은 아니다. 그냥 잡히는 대로 코딩을 시작해보자. 대부분의 관리자는 우리가 만든 코드 줄 수로 생산성을 판단하는 경향이 있다. 따라서 나중에 삭제할 쓸모 없는 코드라도 일단 넣어보자.

중요한 것은 크기

So you have finished reading the 유지 보수 하기 어렵게 코딩 하는 방법 topic article, if you find this article useful, please share it. Thank you very much. See more: 유지보수하기 어렵게 코딩하는 방법 pdf, 코딩 하는법, 한빛아카데미, 로에디 그린, 한빛라이프, 한빛미디어, 유지보수 뜻, 폴리글랏 프로그래밍