노트

보이스카우트 규칙

Boy Scout Rule

설계#refactoring · 연결된 개념 6개

쉽게 말하면

보이스카우트 규칙은 캠핑장을 떠날 때 왔을 때보다 조금 더 깨끗하게 치우고 가자는 거예요. 코드도 만질 때마다 이름 하나, 중복 하나씩 고치면 지저분해지는 속도를 이길 수 있어요.

비유가 깨지는 곳 캠핑장 청소는 그 자리에서 끝내면 되지만, 코드 정리는 하던 작업과 섞이면 곤란해요. 커밋을 나누고, 오래 걸리는 정리는 메모만 남겼다가 하던 일을 끝낸 뒤 해요.

코드를 처음 발견했을 때보다 조금이라도 나은 상태로 남겨 두라는 규칙. 캠핑장을 떠날 때 왔을 때보다 깨끗하게 하라는 보이스카우트 수칙을 로버트 C. 마틴(Robert C. Martin)이 소프트웨어에 옮겼다. 『리팩터링』도 같은 비유를 쓴다.

  • 큰 리팩터링이 아니라 매번의 작은 개선이 핵심이다. 헷갈리는 이름 바꾸기, 중복 하나 없애기, 빠진 테스트 하나 더하기
  • 작은 개선이 쌓이면 기술 부채가 쌓이는 속도를 이긴다
  • 단, 지금 하는 작업과 섞이지 않게 커밋을 나눈다(정리(Tidying)). 시간이 걸리는 것은 메모만 남기고 하던 일을 끝낸 뒤 처리한다
  • "건드렸으면 책임진다"는 태도와 집단 코드 소유가 이 규칙을 가능하게 한다

깨진 유리창 이론(Broken Windows Theory)

깨진 유리창 하나를 방치하면 주변이 빠르게 망가진다는 비유. 코드베이스에 TODO, 죽은 코드, 무시된 경고가 쌓이면 새로 쓰는 코드도 그 수준에 맞춰 낮아진다. 작은 문제라도 발견하는 즉시 고치는 문화가 중요하다.

출처: Laws of Software Engineering: The Boy Scout Rule · Laws of Software Engineering: Broken Windows Theory · 『리팩터링 2판』 마틴 파울러 (원서 Refactoring, 2nd Edition)

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 리팩터링

    겉으로 보이는 동작은 그대로 둔 채, 코드를 이해하고 고치기 쉽게 내부 구조를 바꾸는 일. 기능을 더하는 일이 아니라 다음 변경을 덜 위험하게 만드는 정리다.

  • 섣부른 최적화

    "섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.

  • 구성요소 줄이기

    셀 수 있는 모든 구성요소(파일, 폴더 깊이, 클래스, 함수, 분기, 변수, 테이블, 필드, 테스트 케이스…)는 비용이라는 관점. 심플 디자인의 네 번째 규칙을 실무 기준으로 풀어낸 것이다.

  • 자가 테스트 코드

    결과까지 스스로 판정하는 자동화된 테스트를 갖춘 코드. 사람이 출력을 눈으로 확인할 필요 없이 명령 하나로 "모두 통과"를 알 수 있어야 한다. 리팩터링의 전제 조건이다.

  • 코드 리뷰

    코드 리뷰는 작성자가 아닌 사람이 변경을 읽고 합칠지 판단하는 과정이다. 버그를 잡는 일 말고도, 팀 모두가 코드베이스를 알게 하고(collective-code-ownership) 설계 판단과 관례를 자연스럽게 퍼뜨리는 통로가 된다. 여러 사람이 모두 놓쳐야만 결함이 새어 나가게 만드는 장치이기도 하다 → growing-together

보기 옵션