[CleanCode] 의미있는 이름

코드가 존재하리라

• 코드는 요구사항을 상세히 표현하는 수단
• 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍 그에 대한 결과가 바로 코드
• 궁극 적으로 코드는 요구사항을 표현하는 언어

나쁜코드

• 기능을 마구짜다보면 나쁜코드가 늘어나고 감당이 불가능해지면 결국 회사를 망하게 까지 한다
• 나쁜코드를 짠 나를 보며 자기합리화: “코드를 다듬다가 시간을 허비할까봐,,, 밀린업무로 넘어가려고 ,, 나중에 할려고,,”
• 르블랑의 법칙(Lenelanc’s Law) : 나중은 결 코 오지 않는다

나쁜 코드로 치르는 대가

• 나쁜 코드는 개발 속도를 크게 떨어뜨린다
• 얽히고 설킨 코드를 해독해서 얽히고 설킨 코드를 더해나간다.
• 이런 나쁜 코드가 늘어나다 보면 쓰레기 더미는 점점 높아지고 청소할 방법이 없다. 불가항력
• 나쁜코드는 팀 생산성을 떨어뜨리다가 0에 수렴
• 원대한 재설계의 꿈
  • 재설계를 위해 새롭게 꾸린 팀과 기존 시스템을 유지보수하는 팀 사이의 갈등
  • 새 시스템이 기존 시스템을 따라잡았을 쯔음 현재 시스템이 너무 엉망이라 재설계를 하자고 한다
• 태도
  • 코드가 왜 그렇게 되었을까? “원래 설계를 뒤집는 방향으로 요구사항이 변해서 그래”, “일정이 촉박해서..”라는 변명
  • 나쁜 코드로 인한 프로젝트 실패에 대한 책임감을 가져야 한다.
  • 온갖 핑계를 대가며 나쁜코드를 짜지말자, 지시하는 것이 곧 나쁜코드를 만들어내는 거면 그것을 그대로 따르는 행동은 전문가 답지 못하다.
• 원초적 난제
  • 나쁜 코드는 오히려 업무 속도를 늦춘다. 즉 기한을 맞추지 못하며 오히려 속도가 늦어지게 된다.
  • 결국 정답은 코드를 최대한 깨끗하게 유지하는 습관
• 깨끗한 코드라는 예술?
  • 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할줄 안다는 뜻은 아니다
  • 깨끗한 코드를 작성하려면 청결 이라는 감각을 활용해 절제와 규율 이 필요하다 -> 그 해답은 코드 감각
  • 코드 감각은 나쁜코드를 좋은 코드로 바꾸는 전략도 파악하게 된다.

깨끗한 코드란?

• 비야네 스트롭스트룹(C++ 창시자)

  “나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다 / 의존성을 최대한 줄여야 유지보수가 쉬워진다 오류는 명백한 전략에 의거해 철저히 처리한다 성능을 최적으로 유지해야 사람들이 원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. “

  • 깨끗한 코드는 ‘보기에 즐거운’ 코드
  • CPU 자원을 낭비하는 코드도 우아하지 못하다
  • 나쁜 코드는 나쁜코드를 ‘유혹’한다. 즉 나쁜코드를 고치면서 더 나쁜 코드를 만든다
  • 철저한 오류 처리도 중요하다 즉 세세한 사항까지 꼼꼼하게 신경써야한다.(메모리 누, Race condition, 명명법 등)
  • 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드
  • 깨끗한 코드는 한가지에 ‘집중’한다
• 그래디 부치(Object Oriented Analysis and Design with Application 저자)

  “깨끗한 코드는 단순 직접적이고 잘 쓴 문장 처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다”

  • 코드의 가독성을 강조
  • 코드는 추축이 아니라 사실에 기반해야한다. 반드시 필요한 내용만 담아야한다.
  • 프로그래머가 단호하다는 인상을 줘야한다
• 데이브 토마스(OTI 창림자이자 이클릭스 전략의 대부)

  “깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고, 단위 테스트케이스와 인수 테스트 케이스가 존재한다. 고치기 쉽다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 오직 하나만 제공한다. 의존성은 최소이며, 각 의존성을 명확히 정의한다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기 때문에 코드는 문학적으로 표현해야 마땅하다”

  • 실제로 일긱 쉬운 코드란 다른 사람이 고치기 쉽다
  • 단, 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다
  • TDD개발에 대한 중요성 강조, 즉 아무리 우아하고, 가독성이 높다고 한들 테스트케이스가 없어서 검증이 안된 코드는 클린하지 않다
• 마이클 페더스

  “깨끗한 코드의 특징은 많지만 그 중에서도 모두 아우르는 특징이 하나 있다. 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로, 고칠 궁리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의깊게 짜높은 작품에 감사를 느낀다.”

  • 즉, 깨끗한 코드는 주의깊게 작성한 코드다.
• 론 제프리스(Adventrue in C# 저자)
  • 켄트 벡이 제안한 단순한 코드 규칙으로 구현을 시작한다
    • 모든 테스트를 통과한다
    • 중복이 없다
    • 시스템 내 모든 설계 아이디어를 표현한다
    • 클래스, 메서드, 함수 등을 최대한 줄인다. 1. 주로 중복에 집중한다. -> 여러차례 반복된 코드는 아이디어를 제대로 표현 못한다는 증거 2. 문제의 아이디어를 찾아내 조금 더 명확하게 표현하려 애쓴다. 3. 여러 기능을 수행하는 객체나 메서드도 찾는다. -> 메서드 추축(Extract Method) 리팩터링 기법을 적용해 기능을 멱확히 기술하는 메서드 하나와 기능을 실제로 수해앟는 메서드 여러개로 나눈다. 4. 집합에서 항목 찾기 -> 집합을 추상화 하면 ‘진짜’ 문제에 신경 쓸 여유가 생긴다
  • 중복줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기 등이 깨끗한 코드를 만드는 비결이다.
• 워드 커닝햄(위키 창시자)

  “코드를 읽음면서 짐작했던 기능을 각 루틴이 그대로 수행했다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다

  • 깨끗한 코드는 코드를 독해하느라 머리를 쥐어짤 필요가 없어야하며, 일긍면서 짐작한대로 돌아가는 코드가 깨끗한 코드다
  • 명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드
• 보이스카우트 규칙

  “캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라”

  • 잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야한다. 체크아웃 할때 보다 좀 더 깨끗한 코드를 체크인 한다면 코드는 절대 나빠지지 않는다. 한커번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 그냥 변수 이름 하나 개선하고, 긴 메서드 분할하고, 중복 쪼금 제거하고 이러는 것도 충분하다.