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

자신이 작성한 코드를 다른 개발자가 작업해야 하고, 반대로 다른 개발자가 작업한 코드를 자신이 작업해야 할 때도 있다.

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

1인 개발자 회사에서 일하지 않는 한 다른 개발자들을 고려하지 않고는 고품질의 코드를 작성할 수 없다.

소제목의 이유를 설명한다.

코드가 어떻게 사용되어야 하는지, 무엇을 하는지, 그리고 왜 그 일을 하고 있는지 설명하는 것이 유용하다. 이것이 주석문을 많이 작성해야 한다는 의미는 아니다. 코드를 이해하기 쉽고 코드 자체로 설명이 되게 하는 것이 좋은 방법이다.

이것을 해결하기 위해 아래와 같은 방법을 제시하고 있다.

무언가 문제가 있을 때 코드 컴파일이 중지되거나 테스트가 실패하도록 만드는 것이다.

결국 타입 기반의 인터페이스를 지향하고, 단위 테스트를 잘 만드는 것이 중요하다.

1~2년 전에 작성한 코드를 다시 들여다보는 일은 다른 사람이 작성한 코드를 보는 것과 크게 다르지 않다. 그렇기에 좋은 코드는 다른 사람에게 호의를 베푸는 것이기도 하지만 미래의 자신에게도 유익한 일이다.

실제로 사용 할 만한 순서대로 나열 할 것임

이름 확인: 기능이나 사용법을 직관적으로 전달 할 수 있다.
데이터 유형 확인: 오용을 힘들게 한다.
문서 읽기: 실제로 도움이 되지 않거나, 업데이트의 누락으로 인해 오히려 혼동을 줄 수 있다.
직접 물어보기: 불확실성이 매우 크다. (기억의 부재, 사람의 부재 등)
코드를 살펴보는 것: 가장 확실하지만, 가장 비효율적이다. 이 방법을 사용하는 것이 권장되는 집단은 추상화 계층의 이점을 부정 할 가능성이 크다.

일반적인 계약의 세부 조항에는 상상이나 예측하지 못한 사항들이 숨어 있는 경우가 많다. (ex. 독소조항) 하지만 세부사항을 깊게 들여다보는 사람은 거의 없다.

명백한 사항: 인터페이스에 나타나는 사항 세부 조항: 주석문 및 문서, 표시되지 않은 예외

정확히는 “세부 조항을 봐야지만 올바르게 사용 할 수 있는 코드를 만들지 말라"가 더 옳은 것 같다. 코드의 오용을 막기 위해 세부 조항을 내재화해야 한다.

검사를 통과하지 못하면 예외 발생

체크와 동일 그러나 개발모드나 테스트 코드에서만 적용 (빌드시 제외)