[Code Readability] 1장 도입과 원칙

가독성이 좋은 코드란?

• 분명해야하고, 간단해야 하고 독립적이어야 하고, 구조적이어야 한다.
• 프로덕트의 규모가 커질수록 코드를 작성하는 것보다 읽는 시간이 더 많아진다.
  • 쓰기 편한코드보다 읽기 쉬운 코드가 더 중요하다.
  • 프로덕트의 규모가 큰 경우에만 중요하고, 일시적으로 사용하는 코드는 괜찮다.

가독성을 개선하는 방법

• 기술, 지식을 목적을 생각해서 선택해야 한다.
  • 기술 자체를 사용해보고 싶어서 사용하면 안된다.
• 가치가 있다면 복잡해도 된다.
• 자동 검증을 최대한 활용한다.
  • 컴파일러, 테스트 등을 더 신뢰된다.
• 더 자주 논의 하라
  • 팀원들과 만들면서 계속 이야기한다.
• 계속 배우자
  • 가독성이 높은 코드를 작성하려면 여러 공부가 필요하다.
  • 강의, 훈련, 책, 온라인 기사, 코드 리뷰, 페어 프로그래밍

Policy

• The boy scout rule
  • 캠프장을 처음 발견했을 때보다 더 깨끗하게 해놓고 떠나라
  • 코드를 변경했을때는 항상 그 전보다 조금이라도 더 깨끗하게 만들어야 한다.
  • Add: comments, tests
  • Remove: unnecessary dependencies, members, conditions
  • Rename: classes, functions, variables
  • Break: huge classes, huge functions, nests, call sequences
  • Structure: format, dependencies, abstraction layers, hierarchies
  • Note
    • pull-request or commit을 크게 만들지 말자
      • 구현 전에 리팩토링을 먼저 끝내자
    • 리팩토링의 범위를 정하자
• YAGNI
  • You Aren't Gonna Need It
  • Implement only when required
    • 90% of features for the future are not used
    • Keep structure simple = ready for unexpected change
  • 사용하지 않는 코드는 모두 제거하자
    • classes/functions/variables중에 참조하지 않거나, 주석처리해둔 코드들
  • 이유없이 확장된 코드들
    • 목적없이 하나의 구현체밖에 없는 Abstract Type 등등
  • 주의할 점
    • 확장이나 수정에 대해서 설계때부터 고려해두는게 좋다. ??
• KISS
  • Keep It Simple Stupid
  • 우아한 코드는 항상 가독성이 좋은 것은 아니다.
  • 가능한 단순한 해결책을 선택하라!
  • 가능하면 표준 구현을 따르자
  • 목적과 사용 범위를 제한하자
  • Bad
    • 한눈에 의미를 알기 어렵고, recevier, it등을 이해하기 어렵다.
•  

  

• Good
  • 우아하지는 않지만 변수등으로 나눠줌으로써 훨씬 쉽게 읽을 수 있다.
  •  

• Single Responsibility Principle
  • A class should have only one reason to change
    • 두가지의 무관한 기능을 한 클래스에 섞으면 안된다.
  • Keep responsibility small
    • Split classes
      • Model for each entity
      • Logic for each layer and component
      • Utility for each target type
    • 한마디로 class가 하고 있는 일을 설명할 수 없다면 나눠야한다.
• Premature optimization
  • 너무 이른 최적화는 악의 근원이다.
  • 좋은 최적화는 코드를 더 간단하게 만든다.
  • 나쁜 최적화는 코드를 복잡하게 만든다.
  • // 조금더 공부가 필요함
• 최적화 전에 해야할 행동
  • 최적화를 해야하는 이유는 합리적인가?
    • 가치 vs 복잡성
  • 프로파일/추정치든 근거를 갖고 고민해야 한다.
    • 시간, 메모리, 코드 양, 사용율을 따져봐야한다.

Summary

• Readability is for sustainable development
• The boy scout rule: Make code readable before changing it
• YAGNI: Implement only when required
• KISS: Choose a simple solution, beautiful != readable
• Single responsibility principle: Clarify the scope
• Premature optimization: Profile/estimate before optimization