## 목차 ##



## 나쁜코드 ##

  • 나쁜코드가 만들어지는 과정

    • 출시 압박에 마구짠 코드
    • 기능을 추가할수록 엉망이 되고 결국 감당 불가능한 수준에 이름
    • 상사한테 욕먹을까봐 서둘러 짠 코드
    • 다른 업무가 밀려 후딱 해치우려고 세심한 주의를 기울이지 않은 코드
    • 나중에 손보겠다고 일단 돌아가게만 짠 코드 -> 르블랑의 법칙 : 나중은 결코 오지 않는다.
  • 나쁜 코드로 치르는 대가

    • 코드가 엉망이라 프로젝트 진도가 나가지 못함
    • 코드를 고칠때마다 문제가 생기고 더욱 엉킨 코드가 됨
    • 시간이 지날수록 쓰레기더미는 점점 높아지고 청소를 할 수 없을 지경에 이르름
    • 팀 생산성이 저하하다가 마침내 0으로 수렴
    • 원대한 재설계의 꿈
      • 마침내 기존 프로젝트를 버리고 재설계를 시작(인력, 돈, 시간 소모)
      • 기존 프로젝트보다 괜찮은 결과를 내야한다는 압박에 서둘러 쓰레기를 생산
      • 위의 과정 반복
  • 원초적 난제

    • 누구나 나쁜 코드가 업무속도를 늦춘다는 사실을 안다.
    • 그럼에도 기한을 맞추려 나쁜 코드를 양산할 수 밖에 없는 원초적인 난제가 존재한다.
    • 과연 기한을 맞추려 서두르는 것이 더 빠른 결과를 내는가?
      • 초기에는 그럴지도 모른다. 하지만 시간이 지날수록 코드가 나빠지고 결국은 느리다는 사실!
      • 결론은 빨리가기 위해 시간을 들여라. -> 생각하고 신중히 고민하여 설계하기 위한 시간을 충분히 가지면서 깨끗한 코드를 유지하면서 진행해라.



## 깨끗한 코드 ##

깨끗한 코드의 정의는 전문가마다 다르다.


비야네 스트롭스트룹(Bjarne Stroustrup) - C++ 창시자

  • 우아하고 효율적인 코드
  • 논리가 간단한 코드
  • 최소의 의존성으로 쉬운 유지보수가 가능한 코드
  • 한 가지를 제대로 하는 깨끗한 코드


그래디 부치(Grady Booch) - Objected Oriented Analysis and Design with Application 저자

  • 단순하고 직접적인 코드
  • 잘 읽히는 코드(가독성)
  • 숨겨진 설계자의 의도가 없는 코드
  • 명쾌한 추상화와 단순한 제어문


빅 데이브 토마스(Big Dave Thomas) - OTI 창립자

  • 작성자가 아닌 사람이 읽기 쉽고 고치기 쉬운 코드
  • 단위 테스트와 인수 테스트케이스가 존재하는 코드
  • 의미있는 이름
  • 하나의 기능당 하나의 방법
  • 최소의 명확한 의존성
  • 최소의!!


마이클 페더스(Michale Feathers) - Working Effectively with Legacy Code 저자

  • 주의깊게 짠 코드(고치려 해봐도 결국 제자리로 귀결)


론 제프리스(Rone Jeffries) - Extreme Programming Installed 저자

  • 모슨 테스트를 통과
  • 중복이 없다.(여러 기능을 수행하는 객체 혹은 메소드는 여러 객체 혹은 메소드로 나누기)
  • 명확하게 표현하라.(클래스 이름, 메소드 이름, 변수 이름)
  • 클래스, 메소드, 함수를 최대한 줄인다.


워드 커닝햄(Ward Cunningham) - Wiki 창시자

  • 코드를 읽으며 짐작한 기능을 각 루틴이 그대로 수행



## 결론 ##

쓰레기가 생기지 않게 작은 것에도 신경써 세심하게 주의를 기울여 코드를 짜라. 코드는 최소한의 단위로 쪼개고 쪼개 각 메소드나 객체는 한 가지 일을 제대로 수행하도록 만든다. 그리고 어떤일을 하는지 클래스, 메소드 이름으로 충분히 나타내줘라. 그렇게 하면 어떤 모듈이 정확히 어떤 기능을 수행하는지 명쾌해지고 읽는사람이 쉽게 내용을 파악할 수 있다. 여러 메소드에 비슷한 코드가 있으면 중복이다. 메소드 추출을 해서 하나의 기능을 하는 모듈로 만들어라.

### 보이스카우트 규칙 ###

미국의 보이스카우트가 따르는 간단한 규칙은 개발자들에게 유용하다.

  • 캠프장에 들어올때보다 나갈 때 깨끗하게 해놓고 떠나라.
  • 코드를 체크아웃할 때 보다 수정하여 체크인 할때 조금이라도 깨끗해야한다.
  • 한꺼번에 많이 할 필요도 없다. -> 변수 이름 하나를 바꾸거나 조금 긴 함수를 분할하거나 약간의 중복만 제거해도 충분하다. 이것만 지키면 절대 더 나빠질일이 없다.



이제부터 이러한 일들을 구체적으로 어떻게 하는지 한가지씩 알아보자!

+ Recent posts