TDD는 설계 방법론이 아니다 글을 읽고 쓴 글입니다.

TDD는 안해봤지만 1년 동안 진하게 유닛 테스트 추가하고 레거시 코드를 테스트 가능하게 리팩토링 하면서 느낀 점과 유사하다. 요약하자면

  1. 테스트 가능한 코드는 강한 결합을 회피하고 의존성 역전 원칙만큼은 지키게 해준다.
  2. 단일 책임 원칙과 인터페이스 분리 원칙은 알아서 챙겨야 한다.

작년에는 코드를 테스트 가능하게 만드는 것부터 시작했다. RIBs는 워낙 기본 구조가 잘게 분리되어 있고 각 요소가 단일 책임 원칙을 지키고 있어서 그에 맞춰 짜기만 해도 중요 로직은 어느정도 테스트 가능하다. MVC를 제외한 대부분의 아키텍처가 비슷할 것이다. 그래서 모바일 개발 환경에서는 아키텍처의 손이 뻗지 않은 그 외 15-20프로 정도의 코드에서만 개발자의 설계 역량이 중요한거 같다.

그런데 그 15-20프로의 코드가 매우 중요하다. 앱의 디자인이나 기능과 유사하게 코드도 템플릿화되어 쉽게 복사되고 퍼진다. 어느 정도 코드베이스가 쌓이면 완전히 새로운 설계를 하게 되는 경우는 드물고 기존에 있는 비슷한 기능을 하는 코드를 찾아 쓰게 된다. 그리고 대부분의 사람들은 기존의 코드를 손쉽게 복붙해서 가져간다.

잘못 설계된 공통 모듈이 그에 의존하고 있는 모듈 수십 개과 수십 명의 개발자에게 안 좋은 영향을 주는걸 봤고, 누군가가 집어 넣은 잘못 설계된 구조가 스멀스멀 퍼져나가는걸 목격했다. 불필요한 의존성이 덤으로 딸려오는 바람에 인터페이스 분리 원칙도 못지키게 되고 빌드 시간도 늘어난다. 또한 누군가가 만든 테스트 불가능한 구조가 다른 개발자들이 별 생각없이 가져가 쓰면서 점점 증식되기도 한다. 코드가 안좋아지는 것 뿐아니라 의미없는 코드 리뷰어가 강제되어 리뷰 받으려는 사람, 리뷰 해야하는 사람의 시간을 허비하게 만들었다.

그래서 공통 모듈을 만들거나, 새로운 구조를 도입할때는 앞으로 이 코드가 오랫동안 남아서 미칠 영향을 고려하여 특히나 책임감을 가지고 설계해야 한다. 구글은 코드 리뷰 대원칙에서 이와 같이 말한다. ‘개발자는 맡은 일을 완수하면서도 코드 품질을 개선시켜야 한다. 꾸준히 개선하지 않으면 품질은 절대 나아지지 않는다.’