이직하고 새 회사의 제품 코드를 처음 마주한다. 처음이라 안그래도 낯선데 코드 이해를 더욱 어렵게 만드는 걸림돌들이 있다. 기록해 뒀다가 내가 자리를 잡게 되면 이것들은 꼭 신경써야 겠다고 다짐한다. 그래서 누가 오든 기존의 코드에 접근하는 장벽이 낮아졌으면 좋겠다.
빌드 가능성
코드는 실행되는 결과를 눈으로 볼 때 가장 이해가 잘되는 것 같다. 코드가 실행되기 위해서는 언어에 따라 빌드 과정이 필요한데 이 첫 단추부터 막혀 쉽게 해결이 안되면 사기가 많이 떨어진다. 그래서 프로젝트는 누구나 빌드 가능하도록 환경 설정이 자동화 되어 있거나 상황에 따라서 문서화 되어 있어야 한다.
실행과 테스트 가능성
빌드가 되었다면 이제 실행할 차례다. 프로젝트는 팀원 누구나 실행해서 동작을 테스트할 수 있어야 한다. 이를 위해 테스트 가능한 환경을 구축하는 절차 역시 자동화 되어 있거나 또는 문서화 되어 있어야 한다. 또한 핵심적인 기능들이 어떤 인터페이스를 통해 실행될 수 있고, 어떤 형식의 입력을 받아 어떤 결과를 주는지 문서화 되어 있어야 한다. 가장 좋은 문서는 테스트 코드인 것 같다. 사실 낯선 제품 코드를 마주했을 때 가장 궁금하고 어려운 건 내가 다루려는 기능의 시작 포인트가 어디고 어떤 형식으로 입력을 넣어주어야 하느냐는 것이다. 이걸 모르면 코드 구현을 뒤지며 찾아내야 하는데 어렵고 지치는 일이다.
관찰 가능성
프로젝트는 코드의 실행 상태를 모니터링 할 수 있도록 로깅 환경이 구축되어 있어야 한다. 코드를 사람이 읽고 결과를 예측하는 일은 신뢰가 떨어지고 어렵다. 대신에 코드가 런타임에 실행된 결과를 보면서 코드를 이해하는 건 비교적 쉽고 정확하다.
팔꿈치를 마주한 동료
위에서 말한 세 가지가 자동화 되어 있거나 또는 문서화 되어 있지 않다면 마지막으로 이것 만이라도 있으면 괜찮다고 생각한다. 나와 팔꿈치를 맞대고 함께 할 수 있는 편안한 동료가 옆에 있어야 한다. 환경 설정 같은 일은 이미 이 과정을 거친 동료의 한 마디가 나의 하루 8시간을 아껴주기도 한다.
