참고 도서: 클린 코드 (로버트 C. 마틴)

읽은지 몇 개월 되었지만 이제야 정리 한다.

계속해서 읽어봐야 할 책인것 같다.

코드를 깊게 이해하며 읽어 보지 못했지만 기본적이지만 놓치고 있었던 부분이 많다고 생각이 들어 정리 해 본다.

개발자로써 두고두고 읽어봐야할 책이라고 생각 된다.

• 깨끗한 코드를 작성해야 하는 이유
  • 프로그램을 짜다 보면, 코드를 쓰는 시간보다 코드를 읽는 시간이 훨씬 더 많다.
  • 소프트웨어는 80% 이상이 소위 유지보수다
  • 깨진 유리창의 법칙처럼 사소한 악취는 전체를 오염들게 할 수 있다.
• 훌륭한 소프트웨어 기법은 집중, 침착, 사고라는 규율을 요구한다. 행동이 전부가 아니다. 아래 원칙을 참고하자.
  • 적절한 명명법으로 이름을 신중하게 결정한다.
  • 코드는 누구나 예상하는 위치에 있어야 한다.
  • 과거 이력이나 불필요 해진 주석은 지운다.
  • 그룹 내 일관적인 구현 스타일을 따른다.
  • 문제는 기꺼이 변경 한다. 코드는 인정사정없이 리팩터링 할 수 있어야 발전이 있다.
• 정직하라!
  • 사소한 것에 정직하고 최선을 다해 정직하라.
  • 인간이기에 완벽할 수 없다. 대신 오류를 정직하게 들어내라.
• 나쁜 코드의 대가
  • 나쁜 코드가 쌓일수록 생산성은 배로 떨어진다.
  • 재설계를 꿈꾸지만 기존 기능을 모두 제공하며 새 시스템을 내놓기란 어렵다.
  • 유지보수가 힘들다.
• 깨끗한 코드란?
  • 논리가 간단한 코드
  • 한가지를 잘하는 코드
  • 단호한 코드
  • 읽기 쉬운 코드
  • 주의 깊게 짠 코드

  • 읽으면서 짐작대로 돌아가는 코드

  • 의미있는 이름

  좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

  • 의도를 분명히 밝혀라
  • 그릇된 정보를 피하라: 불필요한 약어 사용 지양, List 등 특수 의미 접미사 지양, 흡사한 이름 지양
  • 검색하기 쉬운 이름을 사용하라
  • 클래스는 명사나 명사구, 메소드는 동사나 동사구가 적합하다.
  • 일관성 있는 어휘를 사용하라.

  • 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야한다. 이것이 제일 어렵다.

  • 함수
    • 함수를 만드는 규칙 첫째도 작게, 둘째도 작게다! 그래야 함수는 읽고 이애하기 쉬워진다.
    • 한가지만 해라!
    • 추상화 수준이 높은 쪽에서 낮으쪽으로 함수를 배치하라!
    • 짧고 어려운 이름보다 길고 서술적인 이름이 더 낫다.
    • 이상적인 인수 개수는 0개다
    • 함수를 어떻게 짜죠?
      • 글쓰기와 비슷하다. 초안은 서투르고 어수선하다.
      • 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스를 만든다.
      • 그런 다음 코드를 다듬고, 고치고, 정리한다. 단위테스트가 변경된 코드의 동일 기능을 보장 한다.
  • 주석
    • 주석은 기껏해야 필요악이다.
    • 주석은 코드로 의도를 표현하지 못한 실패를 만회하기 위함이다.
    • 주석이 필요한 상황에 처하면 코드로 표현할 수 있는 방법을 곰곰이 생각하기 바란다.