Chesterton의 가운데손가락

1 day ago 3

Chesterton’s fence는 이유를 모르는 코드를 함부로 바꾸지 말라는 조언이지만, 이유를 남기지 않은 코드와 커밋 기록은 후임 개발자에게 같은 부담을 떠넘김
해당 저장소의 지난 13년간 커밋 본문은 명령어 기준 295줄뿐이고, dependabot·revert·typo 관련 본문을 빼면 167줄로 줄어듦
커밋 제목은 큰 변경에도 “fix page A”처럼 맥락을 주지 못하며, 별도 문서와 코드 주석도 거의 없어 변경 이유를 추적하기 어려움
코드에는 끝나지 않은 리팩터링, 제거된 기능의 잔재, 추가됐지만 연결되거나 사용되지 않는 기능, 아무도 쓰지 않는 듯한 기능이 남아 있음
커밋 메시지와 문서는 “무엇을 바꾸는지, 왜 바꾸는지, 왜 좋은 해결책인지”를 최소한이라도 남겨야 하며, 아무것도 남기지 않으면 뒤에 오는 개발자의 비용이 커짐

이유 없는 코드가 남기는 부담

Chesterton’s fence는 어떤 것이 왜 그렇게 되어 있는지 이해하지 못했다면 함부로 바꾸지 말라는 비유임
- 프로그래밍에서도 이상해 보이는 코드를 “고쳤다가” 나중에 그 이상함에 이유가 있었음을 알게 되는 일이 생길 수 있음
이 사례에서는 반대편 문제가 드러남
- 이상한 코드와 결정은 많지만, 왜 그렇게 되었는지 알 수 있는 기록이 없음
- 이전 개발자들이 모두 떠난 뒤 고용되어 물어볼 사람도 없음
저장소의 커밋 기록은 실질적인 맥락을 거의 제공하지 못함
- 지난 13년간 커밋 본문은 총 295줄
- dependabot, “revert commit”, “fix typo” 커밋 본문을 수동으로 제외하면 167줄
- 대략 한 달에 한 줄 수준임
커밋 제목도 대개 “fix page A”처럼 큰 변경을 설명하기에는 부족함
별도 문서가 없고, 코드 주석도 거의 없음
이런 상황은 “우리는 이상한 일을 많이 했지만 왜 그랬는지는 말하지 않겠다”는 식의 Chesterton’s middle finger에 가까움

코드베이스에는 여러 종류의 미완성·잔여 코드가 남아 있음
- 끝나지 않은 리팩터링
- 제거된 기능의 잔재
- 추가됐지만 연결되거나 사용되지 않는 기능
- 아무도 사용하지 않는 듯한 기능
전체적으로는 Chesterton’s gap 문제도 심해 보임
- “아직 울타리가 없으니 만들자”는 식으로, 실제로 울타리가 필요한지 묻지 않는 상황에 가까움
좋은 글쓰기는 어렵지만, 대충 통과 가능한 수준의 설명을 남기는 일은 어렵지 않음
변경 기록은 기본적으로 세 가지 질문에 답해야 함
- 무엇을 바꾸는가
- 왜 바꾸는가
- 왜 이 해결책이 좋은가
“Implement new feature X”만으로 충분한 경우도 있지만, 대부분은 기능이 왜 또는 어떻게 그런 방식으로 추가됐는지 적을 내용이 있음
버그 수정, 리팩터링, 실질적인 변경에서는 보통 최소한 한두 문단 정도로 변경 내용과 이유를 남길 수 있음
이런 기록은 선택 사항이 아니라 소프트웨어 개발자의 일에 포함됨
- 유려할 필요 없음
- 완벽한 영어일 필요 없음
- 거창한 에세이일 필요 없음
- 빠뜨리는 내용이 있어도, 아무것도 없는 것보다는 훨씬 나음
아무것도 남기지 않으면 이후의 모든 사람에게 문제를 떠넘기게 됨