실천 사항

이 책의 모든 장이 신선하게 다가왔지만 특히나 이 장은 사고를 넓히게 해줬다.

내가 항상 지키고 따르려고 했던 두가지가 있다.

• 코드리뷰는 항상 Pull Request를 머지하기 전에 해야한다.
• 테스트는 반드시 작성해야한다.

하지만 책에서 말하듯, 모든 것엔 트레이드오프가 있고 옳고 그름 대신에 효과가 있느냐 없느냐의 관점에서 대상을 바라보아야한다.

코드 리뷰도 ‘코드 머지 전에’, ‘반드시 해야한다’는 생각에 벗어날 필요가 있다. 코드 리뷰가 효과를 내는 적절한 균형을 찾는 것이 중요하다.

책 내용

소프트웨어 품질은 균형의 문제다. 어떻게 해야 한다고 규정된 하나의 보편적인 원칙은 존재하지 않는다. 따라서 옳고 그름 대신에 효과가 있느냐 없느냐의 관점에서 대상을 보는 것이 좋다.

좋은 소프트웨어를 만들어야 한다. 그렇지 않으면 소프트웨어를 대충 만들며 아낀 시간보다 이를 다루는 데 더 많은 시간을 낭비하게 된다.

고품질의 코드베이스를 만드는 몇 가지 전략과 여기에 수반하는 몇 가지 손익을 살펴보자.

지속 가능한 코드 리뷰 프로세스를 만들어라

코드 리뷰가 개발자에게 제공하는 명확한 혜택은 다음과 같다.

• 설계 결함이나 버그를 초기에 포착한다.
• 코드 변경사항에 대한 책임감이 강해진다.
• 좋은 코드 작성법을 배우는 모델로써 도움이 된다.
• 코드베이스에 관한 실용적 지식을 공유한다.
• 장기적인 작업 속도가 향상된다.

코드를 리뷰하지 않는 개발자는 코드 리뷰가 코드 품질 개선에 도움이 된다는 것을 인정하면서도, 종종 리뷰가 개발 주기 반복 속도에 미치는 영향에 대해 우려를 표명한다. 코드 리뷰에 드는 시간과 노력을 제품 개발의 다른 측면에 쓰는 것이 더 낫다고 주장한다.

코드 리뷰를 하는 것이 합리적일까? 해야한다 하지말아야한다의 이분법적인 사고 방식은 벗어나자.

• 구글은 코드의 모든 변경사항을 반드시 리뷰하게 한다.
• 인스타그램은 초창기에 모니터를 공유해서 다른 사람의 코드를 살펴보게 하는 오버 더 숄더 리뷰 방식을 활용했다.
• 스퀘어와 트위터는 코드 리뷰 대신에 페어 프로그래밍을 많이 활용했다.
• 우얄라에서는 코드 리뷰를 도입한 당시, 팀을 참조한 이메일에 댓글을 달고 핵심 기능의 까다로운 부분만 리뷰했다.
• 쿼라에서는 비즈니스 로직의 모델과 컨트롤러 코드에 대한 리뷰만 요청했다. 대부분의 코드를 프로덕션에 푸시한 후에 리뷰했다.

코드 리뷰가 효과를 내는 적절한 균형을 실험을 통해 찾아보라. 우얄라는 초기에 코드 리뷰 없이 운영했다. 하지만 품질이 떨어지는 코드가 제품 개발을 방해하는 것을 깨닫고 결국은 품질을 높이는 하나의 방법으로 리뷰를 도입했다.

추상화를 통해 복잡성을 관리하라

올바른 추상화를 선택하면 프로그래밍이 설계부터 자연스럽게 흘러간다. 모듈 인터페이스는 작고 간단할 것이고 광범위한 개편이 없어도 새로운 기능이 잘 안착할 것이다. 잘못된 추상화를 선택하면 프로그래밍하는 동안 예상 밖의 문제가 줄줄이 일어난다. 인터페이스는 예상치 못한 인터랙션을 억지로 수용하기 위해 찌그러지거나 투박해질 것이고 아주 간단한 변경조차 하기 어려워진다.

위 인용문은 올바른 추상화가 엔지니어링 생산성을 어떻게 높이는지 보여준다.

• 원래 문제의 복잡성을 이해하기 쉬운 원시 형태로 분해해준다.
• 애플리케이션 유지 보수에 드는 수고가 줄고 개선사항을 적용하기 쉬워진다.
• 어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용할 수 있다.

좋은 추상화는 다음과 같은 속성이 있다.

• 배우기 쉽다.
• 문서가 없어도 사용하기 쉽다.
• 잘못 사용하기 어렵다.
• 요구 조건을 충족시킬 정도로 충분히 강력하다.
• 확장하기 쉽다.
• 대상 사용자에게 적합하다.

좋은 추상화를 설계하려면 수고가 필요하다. 추상화를 처음 설계할 때 도움이 되는 몇 가지 아이디어를 소개하면 다음과 같다.

• 회사의 코드베이스나 깃허브 저장소에서 인기 있는 추상화를 찾아라. 관련 문서를 읽고 소스 코드를 살펴보고 이를 확장해보라.
• 구글, 페이스북, 링크드인, 트위터 같은 IT 기업의 오픈 소스 프로젝트를 살펴보라.
• 인기 있는 API 인터페이스를 연구하라. 드롭박스, 페이스북, 아마존 웹 서비스 등에서 개발한 것이 좋은 예다.

테스트를 자동화하라

코드의 상당 부분이 출시된 제품에 포함되지 않는 상황에서 테스트에 대한 투자를 정당화하기 어렵다.

보통 첫 번째 테스트를 작성하는 게 가장 어려운데, 결국 한 개발자가 기본적인 자동 테스트를 작성하면, 시간이 절약된다는 것을 확인하자 사람들은 개발 속도를 높이는 데 도움이 될 만한 다른 테스트를 찾는다.

대규모 코드베이스를 작업할 때 테스트를 작성하는 습관을 들일 효과적인 방법은 레버리지가 높은 테스에 집중하는 것이다. 즉, 작성하는 데 든 시간에 비해 많은 시간을 절약해주는 테스트에 집중하는 것이다. 그러니 가장 가치 있는 테스트부터 시작하여 한 걸음씩 전진하라.

기술 부채를 상환하라

가끔 단기로는 타당하나 장기로는 비용이 많이 드는 방식으로 작업할 떄가 있다. 어느 순간을 지나 부채가 너무 늘어나면 발전을 방해한다. 더 효과적인 개발자가 되려면 기한에 맞춰 업무를 완료해야 할 때는 어쩔 수 없이 기술 부채를 만들지만, 대신 주기적으로 그 부채를 상환해야 한다.

팀의 실행 능력이 눈에 띄게 떨어질 정도로 개발 속도가 느려져서 기술 부채가 너무 늘어났다는 것이 확인되면 명시적으로 재작성 프로젝트 일정을 잡고 여기에 수반되는 위험을 감수하는 회사도 있다.

• 구글은 개발자들이 특정 주제 관련 문제를 처리하도록 권장하는 픽스잇 데이(Fixit day)를 개최해 기술 부채를 상환하는 가벼운 장치로 활용한다.
• 링크드인은 회사가 상장된 후 2개월 동안 신규 기능 개발을 잠시 멈췄다. 그리고 망가진 프로세스를 수정하는 시간으로 삼았다. 그 결과 새로운 기능을 배초하는 데 한 달이나 걸렸는데 휴지기 뒤에는 개발 속도가 훨씬 더 빨라졌다.

모든 기술 부채가 상환할 가치가 있는 것은 아니다. 코드베이스에서 더 자주 읽고 호출하고 수정하는 부분일수록 기술 부채 이자가 높아진다. 제품의 주변부에 있는 코드나, 읽고 수정하는 일이 거의 없는 코드는 설사 기술 부채가 잔뜩 쌓여 있더라도 전체 개발 속도에 영향을 미치지 않는다.

핵심 요약

• 코드를 리뷰하는 문화를 확립하라
• 좋은 소프트웨어 추상화에 투자하여 어려운 문제를 단순화하라
• 자동 테스트로 코드 품질을 향상시켜라
• 기술 부채를 관리하라