좋은코드 나쁜코드: 프로그래머의 코드 품질 개선법(PART I 이론)
CHAPTER 3 다른 개발자와 코드 계약
예측 가능한 코드를 작성하라, 코드를 오용하기 어렵게 만들라 두가지 원칙은 다른 사람이 작성한 코드와 상호작용할 때 일어날수 있는 일과 관련 있다
자신의 코드와 다른 개발자의 코드
1인 개발자 회사에서 일하지 않는한 다른 개발자들을 고려하지 않고는 고품질 코드를 작성할 수 없다
코드를 작성할때 고려할것
- 자신에게 명백하다고 해서 다른 사람에게도 명백한 것은 아니다
- 자신은 문제를 해결하기 위해 몇시간 또는 몇일을 보냈지만 수정하는 사람은 충분한 시간을 갖지 못했던 사람이 수정해야 된다.
- 다른 개발자는 무의식중에 여러분의 코드를 망가뜨릴 수 있다
- 문제가 생기면 컴파일이 중지 되거나 테스트가 실패하도록 만드는것이 병합을 중지시킬수 있는 일이다
- 시간이 지남에 따라 자신의 코드를 기억하지 못한다
- 코드는 이해하기 쉬어야 하고 잘작동 하던 코드에 버그가 발생하는것이 어려워야 된다 다른 사람에게 호의를 베푸는것이고 미래의 자신을 위한 길이기도 하다
여러분이 작성한 코드의 사용법을 다른 사람들은 어떻게 아는가?
- 여러 가지 상황에서 어떤 함수를 호출해야 하는지
- 클래스가 무엇을 나타내는지 그리고 언제 사용되어야 하는지
- 어떤 값을 인수로 사용해야 하는지
- 코드가 수행하는 동작이 무엇인지
- 어떤 값을 반환하는지
코드가 어떻게 사용해야 하는지 알아내는 방법
- 함수, 클래스, 열거형 등의 이름을 살펴본다
- 이름을 잘짓는것이 다른 개발자가 어떻게 사용해야 하는지 가장 잘 전달할수 있는 방법이다.
- 함수와 생성자의 매개변수 유형 또는 반환값의 유형 같은 데이터 유형을 살펴본다
- 유형 시스템을 사용하는 언어로 코드를 작성하는것은 오용하거나 오작동하지 못하게 하기 위한 좋은 방법이다.
- 함수/클래스 수준의 문서나 주석문을 읽어본다.
- 함수및 클래스 수준의 비공식 주석문
- 자바독과 같은 좀더 공식적인 코드 내 문서
- 외부문서
- 단점
- 다른 개발자가 이 문서들을 읽을 것이라는 보장이 없으며 실제로 읽지 않을 떄가 많다
- 설령 읽더라도 잘못 해석할 수 있다
- 문서의 업데이트가 제대로 안 될수 있다
- 직접 와서 묻거나 채팅/이메일을 통해 문의한다
- 단점
- 코드를 많이 작성할수록 질문에 답하는 데 더 많은 시간을 써야 할 것이다
- 코드작성자가 휴가를 가면 물어볼사람이 없다
- 1년이 지나면 자기 자신도 그 코드를 기억하지 못한다 그래서 제한된 기간 동안만 효과가 있다.
- 코드를 작성한 사람이 회사를 떠날수도 있는데 그러면 코드를 사용하는 방법에 대한 지식이 사라져 버린다.
- 단점
- 여러분이 작성한 함수와 클래스의 자세한 구현 코드를 읽는다.
- 코드의 양이 많으면 효과를 얻기 힘들다
- 추상화 계층을 만드는 데 있어 요점은 개발자가 한 번에 몇 가지 개념만 처리해야 하고 그 문제가 어떻게 해결되었는지 정확히 알지 못하더라고 하위 문제에 대한 해결책을 사용할수 있어야 된다
코드 계약
계약에 의한 프로그래밍 또는 계약에 의한 디자인
코드의 계약에 대한 용어의 범주
- 선결 조건 : 코드를 호출하기 전에 사실이어야 하는것
- 사후 조건 : 코드가 호출된 후에 사실이어야 하는것
- 불변 사항 : 코드가 호출되기 전과 후에 시스템 상태를 비교해서 변경되지 않아야 하는 사항
어떻게 하면 코드를 사용하는 사람이 계약을 파악하고 따라갈 수 있을지에 대해 생각하는 것이 중요하다
계약이 명확한 부분
- 함수와 클래스 이름
- 인자 유형
- 반환 유형
- 검사 예외(checked exception)
세부 조항
- 주석문과 문서
- 비검사 예외(unchecked exception)
세부조항에 너무 의존하지 말라
- 세부조항은 일반적으로 코드 계약을 전달하기 위해 신뢰할 만한 방법이 아니다
- 세부조항을 제거하는 방법
- 정적팩토리 함수
- 상태나 가변성이 클래스 외부로 노출되는 것을 없엔다
체크 및 어서션
컴파일러를 사용하여 코드 계약을 확인하는 것에 대한 대안으로 런타임 검사를 사용할 수 있다.
컴파일러를 사용하여 계약을 강제할수 있는 실질적인 방법이 없는 상황이 더러 있다.
이러한 경우 런타임 검사를 통해 계약을 확인하는 것이 아예 계약을 확인하지 않는 것보다 낫다.
체크
- 코드 계약 조건을 확인하기 위한 일반적인 방법은 체크를 사용하는 것이다.
- 체크는 신속한 실패와 밀접한 관계가 있다.
체크가 계약조건에 따라 구분 되는 범주
- 전제 조건 검사 : 입력 인수 확인, 일부 코드가 실행전에 유효한 상태인지 확인하는 경우
- 사후 상태 검사 : 반환값이 올바르거나 일부 코드 실행후 유효한 상태인지 확인하는 경우
체크의 효과는 보장 되지 않는다
- 테스트하기가 불분명한 상황에서 확인 중인 조건이 위반된다면, 코드가 배포되고 사용자가 사용하기 전까지 버그가 미노출
- 체크가 잘 작동해서 실패가 명백함에도 불구하고 아무도 알아차리지 못할 위험이 있다. 예외가 일어나더라고 시스템 작동이 엄추지 않게 상위 수준에서 예외가 처리되어
로그가 잘 기록 되어도 개발자가 신경쓰지 못하면 아무도 알아차리지 못 한다.
코드에 체크가 많이 있으면 세부 조항을 없에는 것에 대해 고려해봐야 되는 신호일지도 모른다