3장 - 다른 개발자와 코드 계약

우리는 팀으로 일한다

정확한 숫자는 중요하지 않지만 일반적으로 우리는 두세 명으로 이루어진 팀에서 소프트웨어에 대한 작업을 수행합니다.

이때 내가 작성한 코드 위에 또 다른 추상화 계층이 쌓일 수 있으며 혹은 내가 작성한 코드를 기반으로 하위 문제를 해결하기 위해 재사용할 수도 있습니다.

 

결국 중요한 것은 내 코드가 다른 개발자에 의해 재사용된다는 것입니다.

또한 소프트웨어의 요구사항은 매번 바뀌고 다른 개발자들이 활발하게 코드를 변경하더라도 튼튼하고 사용하기 쉬어야 합니다.

 

따라서 세 가지를 고려하는 것이 좋습니다.

• 나에게 명백하다고 해서 다른 사람도 그럴 것이라 생각하면 안 된다.
• 다른 개발자가 무의식 중에 내 코드를 망가뜨릴 수 있다.
• 시간이 지나면 내가 작성했던 코드를 기억하지 못한다.

 

다른 사람의 코드를 파악하는 방법

• 함수, 클래스, 열거형 등의 이름을 살펴보면서 이해하기 (우리가 이름을 매우 신중하게 짓는 이유)
• 함수와 생성자의 매개변수 반환값 살펴보기
• 함수/클래스 수준의 문서나 주석문을 읽어보기 (문서가 최신이 아니면 어떻게 하지?)
• 직접 찾아가서 문의 (퇴사 휴가라면 어떻게 하지?)
• 작성한 함수와 클래스의 자세한 구현 코드를 파악하기(코드가 엄청나게 많다면...)

처음 세 가지만이 실제로 사용할만한 다른 사람의 코드를 파악할만한 방법입니다.

 

계약의 세부 조항

일상생활에서 모든 약관의 문장을 주의 깊게 읽으시나요? (저는 아닙니다)

예를 들어 스쿠터를 예약한다면 스쿠터를 시간당 10달러에 대여한다는 것을 명백하게 알 수 있습니다.

또한 예약 버튼을 누르면 계약이 성립한다는 것도 명백하게 알 수 있습니다.

 

하지만 약관과 같은 세부 사항에서는 우리가 예상하지 못한 것들도 존재할 수 있습니다.

• 사고 시 수리 비용을 지불해야 한다.
• 시 경계를 넘어서면 100달러 벌금을 부과한다.

 

첫 번째 세부 사항은 예측가능하지만 두 번째 세부 사항은 그렇지 않습니다

 

이처럼 세부 조항은 쉽게 간과될 수 있기 때문에 다른 사람들이 그것을 읽어볼 것이라 기대하기 어렵고 코드에서 주석이 비슷한 역할을 수행합니다.

 

예를 들어 주석으로 코드의 호출 순서를 명확하게 써놓는 것보다는 정적 팩토리 함수를 활용하여 호출 순서를 강제하는 것이 더 좋습니다.

이제 개발자의 실수에 의해 잘못된 상태에서 호출될 가능성이 사라지게 됩니다.

비슷하게 어떤 상태(state)나 가변성(mutability)이 클래스 외부로 노출되는 것을 없애는 것도 활용할 수 있습니다.

 

물론 누군가는 팩토리 함수를 활용하지 않고 억지로 코드를 변경해서 사용할 수도 있습니다 하지만 최소한 변경하면서 한 번쯤을 생각해 볼 수 있는 여지를 줍니다.

 

세부 조항을 검증하기

• assert
• check

 

컴파일 타임에서 체크할 수 없다면 언어 별로 다르겠지만 런타임에서 코드 계약을 준수하도록 강제하는 방법으로 assert나 check 등을 활용할 수 있습니다.

예를 들어 kotlin에도 check, require 등이 지원됩니다.