3. 다른 개발자와 코드 계약

3.1 자신의 코드와 다른 개발자의 코드

• 서로 작성한 코드가 쌓임
• 활발하게 코드를 변경하더라도 코드의 품질이 유지되려면 코드가 튼튼하고 사용하기 쉬워야 함
• 자신에게 분명하다고 해서 다른 사람에게도 분명한 것은 아님
  • 그들은 그 문제를 이해하고 어떻게 해결할지에 대해 생각할 수 있는 시간을 아직 충분히 갖지 못한 상태
  • 코드를 이해하기 쉽고 코드 자체로 설명이 되가 하는 것이 좋음
• 내 코드는 독립적으로 존재하지 않는다
  • 다른 개발자가 의도치 않게 잘 실행되던 코드를 작동하지 않게 하거나 오용할 수 있음
  • 무언가 문제가 있을 때 컴파일 중지시키거나 테스트 실패하도록 만들자
• 1년이 지난 코드를 다시 들여다보는 일은 다른 사람이 작성한 코드를 보는 것과 크게 다르지 않음
  • 배경지식이 전혀 없는 사람에게도 자신의 코드가 이해하기 쉬워야 함

3.2 여러분이 작성한 코드의 사용법을 다른 사람들은 어떻게 아는가?

• 함수, 클래스, 열거형 등의 이름을 살펴본다
  • 편리하고 빠른 방법
  • 어떻게 사용해야 하는지에 대해 가장 잘 전달할 수 있는 방법 중 하나
• 함수와 생성자의 매개변수 유형 또는 반환값의 유형 같은 데이터 유형을 살펴본다
  • 정적 유형의 언어에서는 올바르지 않은 경우 컴파일되지 않음
• 함수/클래스 수준의 문서나 주석문을 읽어본다
  • 비공식적인 주석문, javaDoc같은 공식적인 코드 내 문서, 외부문서(readme 등)
  • 실제로 읽지 않음
  • 업데이트 안될 가능성 높음
• 직접 와서 묻거나 채팅/이메일을 통해 문의한다
  • 지속가능성 없음
  • 내가 코드 기억 못할수도..
• 여러분이 작성한 함수와 클래스의 자세한 구현 코드를 읽는다
  • 의존하고 있는 라이브러리가 많으면 적당한 크기의 기능을 구현하려 해도 수십만 줄의 코드를 읽어야 할 수도
  • 세부 코드를 읽어야만 한다면 추상화 계층의 많은 이점을 부정하는 꼴

3.3 코드 계약

• 계약에 의한 프로그래밍
  • 어떤 코드를 호출하는 코드는 특정 요건을 충족해야 함
  • 선결조건
  • 사후조건
  • 불변사항
• 명백한 사항과 세부 조항
  • 계약의 명확한 부분
    • 함수와 클래스 이름
    • 인자 유형
    • 반환 유형
  • 세부 조항
    • 주석문과 문서
• 잘못된 일을 하는 것을 처음부터 불가능하게 만들어라
• 체크나 어서션을 사용하는 방법도 있음, 그러나 아예 불가능하게 만드는 것보다는 이상적이지 않다