좋은 코드를 작성하는 법 (사내 세미나)

좋은 코드의 기준

---

• 기준이 너무 많으면 이해하기 어렵다
• 가독성
  • 코드는 읽기 쉬어야 가독성이 좋다?
  • 사람마다 읽기 쉬운 코드는 다르다
  • 가독성이라는 표현은 모호하다

Kent Beck의 Simple Design

---

• 좋은 코드의 기준
  • 테스트가 다 통과한다
  • 개발자의 의도가 들어나야 된다
  • 중복이 없어야 한다
  • 속성이 최소로 구성되어야 한다
• 기준이 4개인 것은 너무 많으므로 하나로 줄이면 다음과 같다
  • “중복이 없으면서 구성요소가 최소한인 코드”
    • 코드에서 중복을 제거한다
    • 그러면서 구성요소를 줄일 방법을 찾는다
• 중복을 제거하는 것은 어렵다
  • Extract Method의 위험성
  • Long Method는 나쁘지만 Extract Method는 더 나쁠 수 있다.
• 정적인 코드와 동적으로 실행되는 프로세스 사이의 개념적 불일치
  • 나쁜 것은 점프다
• Side Effect를 제거하라
  • 순수함수
  • Mutator와 Accessor를 구분하라
    • Mutator : 값을 바꾸는 함수
    • Accessor : 결과 값을 반환하는 함수
• 중복 제거를 위해 메서드를 뽑아내는 것은 대체로 안전하다
• 구성 요소를 제거하는 방법
  • 클래스, 메서드, 분기, 변수, …
  • 생각할 수 있는 모든 요소를 줄여라

Simple Design을 방해하는 관점

---

• 코드 품질을 높이려면 더 많은 시간이 필요하다?
  • 코드 품질이 중요한 건 더 빨리 완료하기 위해서이다.
• 리팩토링을 안했기 때문에 시간이 없는 것이다.
  • 작은 단위로 리팩토링 해야 문제가 발생하지 않는다.
• 처음부터 제대로 해야 한다?
  • 처음부터 완벽하게 설계할 수는 없다
• 자동화는 항상 좋은가?
  • 복잡한 것을 자동화하면 복잡합이 고착화되어서 바꾸기 어려워진다.
  • 먼저 단순화하고 자동화하라

Simple Design, 얼마나 철저하게 할 것인가?

---

• 전문가는 유연하게 할 수 있으며, 초보자라면 극단적으로 수행하면서 개선하는 것이 좋다.

애자일 방법론

---

애자일 선언문

• 프로세스와 도구보다 개인의 판단과 의사소통을 중시한다.
• 포괄적인 문서보다 작동하는 소프트웨어를 중시한다.
• 계약 협상보다 고객 협력을 중시한다.
• 계획을 지키는 것보다 변화에 대응하는 것을 중시한다.

Extreme Programming Roadmap

• 최대한 단순하게 구현한다.
• 문서화보다 코드를 중시한다.
• 눈에 보이는 것을 바로 리팩토링한다.

도요타 웨이에서 말하는 7대 낭비

• Overproduction -> Overengineering, 고객이 원하지 않는 기능
• Waiting -> 개발자와 기획자 소통 병목, 변경 사항을 기다리는 것
• Transport -> 고객에게 전달되지 않은 코드
• Extra Processing
• Inventory -> 배포하지 않은 코드
• Motion -> 복잡한 환경, 복잡한 배포 및 테스트 절차
• Defect

• 처음부터 설계를 잘해야 좋은 코드가 나온다?
  • 조금씩, 그러나 지속적으로 개선해 가는 방법이 필요하다.
• 코드 품질의 중요성을 팀에서 다루는 방법
  • 비즈니스 가치, 고객 클레임, 서버 안정성 등의 가치들보다 코드 품질을 중시하라.