다른 개발자와 코드 계약

내가 작성한 코드의 사용법을 다른 사람은 어떻게 아는가?

다른 사람이 코드를 파악하려면 다음과 같은 사항을 이해 해야한다.

• 여러 가지 상황에서 어떤 함수를 호출해야 하는지
• 클래스가 무엇을 나타내는지 그리고 언제 사용되어야 하는지
• 어떤 값을 인수로 사용해야 하는지
• 코드가 수행하는 동작이 무엇인지
• 어떤 값을 반환 하는지

그리고 다른사람이 코드를 파악하기 위해선 아래와 같은일을 한다.

• 함수, 클래스, 열거형 등의 이름을 살펴본다.
• 함수와 생성자의 매개변수 유형 또는 반환값의 유형 같은 데이터 유형을 살펴본다.
• 함수/클래스 수준의 문서나 주석문을 읽어본다.
• 직접 와서 묻거나 채팅/이메일을 통해 문의한다.
• 여러분이 작성한 함수와 클래스의 자세한 구현 코드를 읽는다.

위 내용중 아마 처음 세 가지만이 실제로 사용할 만하고 이름과 데이터 유형을 확인하는 것이 문서를 읽는 것보다 더 신뢰할 만하다. 네번째의 경우엔 코드를 작성한지 얼마 안됐을때는 효과적일 수 있으나 그렇지 않은 경우에는 신뢰하기 힘들다.

코드 계약

코드의 계약에 대한 용어를 다음과 같은 세가지 범주로 나누면 유용하다.

• 선결 조건(precondition) : 코드를 호출하기 전에 사실이어야 하는 것, 예를 들어 시스템이 어떤 상태에 있어야 하는지, 코드에 어떤 입력을 공급해야 하는지와 같은 사항

• 사후 조건(postcondition) : 코드가 호출된 후에 사실이어야 하는 것, 예를 들어 시스템이 새로운 상태에 놓인다든지 반환되는 값과 같은 사항

• 불변 사항(invariant) : 코드가 호출되기 전과 후에 시스템 상태를 비교해서 변경되지 않아야 하는 사항

개발자가 계약의 일부 혹은 모든 조건을 알지 못하면 코드 계약에 문제가 발생한다. 코드를 작성할때 만들어지는 계약의 내용이 무엇일지 그리고 어떻게 하면 코드를 사용하는 사람이 계약을 파악하고 따라갈 수 있을지에 대해 생각하는 것이 중요하다.

체크 및 어서션

1.체크

체크는 시행중인 계약 조건에 따라 다음과 같은 범주로 구분된다.

• 전체 조건 검사 : 예를들어 입력수가 인구 올바르거나, 초기화가 수행되었거나, 일부 코드를 실행하기 전에 시스템이 유효한 상태인지 확인하는 경우

• 사후 조건 검사 : 예를들어 반환값이 올바르거나 일부 코드를 실행한 후 시스템이 유효한 상태인지 확인하느 경우

2. 어서션

어서션은 체크와 거의 같은 방식으로 동작한다. 체크와 차이점은 배포를 위해 빌드할 때 어서션은 보통 컴파일에서 제외된다는 점이며,
컴파일에서 제외되는 이유는 다음과 같다.

• 성능 향상을 위해 : 조건이 위반되는지 확인하려면 CPU사이클이 필요하다. 코드에서 어서션이 많으면 소프트웨어의 전반적인 성능이 눈에 띄게 저하될 수 있다.

• 코드 오류 발생률을 낮추기 위해 : 이것이 유효한 동기인지 아닌지는 특정 응용 프로그램에 달려있다. 이로 인해 버그가 눈에 띄지 않을 가능성이 증가하지만 버그 발생 가능성 방지보다 고가용성이 더 중요한 시스템이라면 배포 시에 컴파일에서 제외하는 것은 적절한 절충이 될 수있다.

요약

• 코드베이스는 계속 변하고 일반적으로 여러 개발자에 의해 변경된다.
• 다른 개발자가 어떻게 코드를 해석하고 오용할 수 있을지 생각해보고, 이러한 가능성을 최소화 하거나 오용이 불가능하게 만드는 방식으로 코드를 작성하는 것이 유용하다.
• 코드를 작성할 때 일종의 코드 계약이 항상 만들어진다. 여기에는 명백한 항목이나 세부 조항과 같은 내용이 포함될 수 있다.
• 코드 계약의 세부조항은 다른 개발자가 계약을 준수하도록 하기 위한 방법이지만 신뢰할만한 방법은 아니다. 보통 더 나은 접근범은 명백한 항목으로 계약의 내용을 전달하는 것이다.
• 일반적으로 컴파일러를 사용하여 계약을 확인하는 것이 가장 신뢰할 수 있는 방법이다. 이것이 가능하지 않을 때, 체크나 어서션을 사용하여 실행 시간에 계약을 확인할 수 있다.