깨끗한 코드

  • 그들(관리자들)이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
  • 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
공통 적으로 이야기하는 내용
  • 가독성
  • 되도록이면 작은 단위로
  • 이름의 중요성
  • 기능은 한가지만 실행하도록
그 외
  • 의존선을 최대한 출여야 한다. (Bjarne Stroustrup)
  • 세세한 사항까지 꼼꼼하게 신경써야 한다. = 세세한 오류 처리 (Bjarne Stroustrup)
  • 깨끗한 코드는 잘 쓴 문장처럼 읽힌다. (Grady Booch)
  • 코드는 추측이 아니라 사실에 기반해야 한다. 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야 한다.(Grady Booch)
  • 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다.(Dave Thomas)
  • 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다.(Micheal Feathers)
  • Ron Jeffries
    • 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기
    • 모든 테스트를 통과한다.
    • 중복이 없다.
    • 시스템 내 모든 설계 아이디어를 표현한다.
    • 클래스, 메서드, 함수 등을 최대한 줄인다.
우리는 저자다
  • … 우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.
  • …급하다면, 서둘러 끝내려면, 쉽게 짜려면. 읽기 쉽게 만들면 된다.
결론
  • 예술과 관련된 책을 읽었다고 해서 예술가가 될 수 있는 것은 아니다. 책을 읽는 것만으로 끝나는 것이 아니라 습관을 들이려고 노력하고 많은 시간동안 공들여 연습해야 좋은 코드를 작성 할 수 있다.

의미있는 이름

권장하는 이름 짓기
  • 분명한 의도
  • 의미있는 구분
  • 검색하기 쉬운 이름 사용
  • 한 개념에는 한 단어만
  • 해법 영역에서 가져온 이름 사용
  • 문제 영역(전문가 영역)에서 가져온 이름 사용
  • 의미있는 맥락 추가
  • 클래스 이름(or 객체 이름)
    • 명사나 명사구가 적합. 동사는 사용하지 않는다.
  • 메서드 이름
    • 동사나 동사구가 적합
하지 말아야 하는 이름 짓기
  • 그롯된 정보 피하기
  • 인코딩 피하기
  • 기억력을 믿지 않기
  • 기발한 이름 피하기
  • 말장난 금지
  • 불필요한 맥락 삭제