죽은 코드 제거

Remove Dead Code

쉽게 말하면

죽은 코드는 아무 데도 연결 안 된 벽 스위치 같은 거예요. 눌러도 아무 일이 없는데 누가 왜 달아 놨는지 몰라서, 볼 때마다 '이걸 건드려도 되나' 고민하게 만드니 지우는 게 나아요.

비유가 깨지는 곳 벽 스위치는 떼면 다시 달기 번거롭지만, 코드는 버전 관리 이력에서 언제든 꺼낼 수 있어요. 그러니 주석 처리로 남기지 말고 지운 뒤 커밋 메시지에 무엇을 지웠는지 적어요.

더 이상 실행되지 않거나 필요 없어진 코드를 지우는 일. 죽은 코드는 "무시해도 된다"는 신호를 주지 않기 때문에, 읽는 사람은 그 코드가 왜 있는지 이해하려고 시간을 쓰고, 고쳤는데 결과가 안 바뀌는 이유를 찾느라 헤맨다.

버전 관리(Version Control)를 믿고 지운다. 나중에 필요하면 이력에서 꺼내면 되고, 커밋 메시지에 무엇을 지웠는지 남겨 두면 찾기 쉽다
주석 처리로 남겨 두지 않는다
테스트에서만 쓰이는 함수·클래스는 미래를 위해 미리 만든 추측성 일반화일 때가 많다. 테스트부터 지우고 코드를 지운다
지우고 나면 남은 코드의 읽는 순서나 배치를 다시 정리할 기회가 생긴다(문장 슬라이드하기)
번들 단계에서 쓰지 않는 export를 걸러 내는 트리 셰이킹은 같은 생각의 도구 버전이다

방치된 죽은 코드와 TODO는 깨진 유리창이 되기 쉽다. 켄트 벡도 정리 기법 2장 "안 쓰는 코드(Dead Code)"에서 같은 이야기를 한다.

연결된 개념

리팩터링
겉으로 보이는 동작은 그대로 둔 채, 코드를 이해하고 고치기 쉽게 내부 구조를 바꾸는 일. 기능을 더하는 일이 아니라 다음 변경을 덜 위험하게 만드는 정리다.
정리(Tidying)
동작을 바꾸지 않는 아주 작은 구조 변경. 켄트 벡은 리팩터링이라는 말이 "기능 개발 중간의 긴 공사"처럼 쓰이며 동작 보존 원칙이 흐려지자, 더 작고 겁나지 않는 단위를 정리라는 이름으로 따로 불렀다. refactoring의 부분집합이다.
테스트 주도 개발 (TDD)
코드를 쓰기 전에 실패하는 자동화된 테스트부터 쓰고, 그 테스트를 통과시킨 뒤 중복을 없애는 짧은 주기를 반복하는 개발 방식. 켄트 벡이 정리했다.
섣부른 최적화
"섣부른 최적화는 모든 악의 근원이다." 도널드 크누스(Donald Knuth)가 1974년 글 「Structured Programming with go to Statements」에서 쓴 말이다. 원문의 맥락은 작은 효율은 대부분(약 97%)의 경우 잊으라는 것이고, 정말 중요한 3%는 놓치지 말라는 말이 이어진다.
자가 테스트 코드
결과까지 스스로 판정하는 자동화된 테스트를 갖춘 코드. 사람이 출력을 눈으로 확인할 필요 없이 명령 하나로 "모두 통과"를 알 수 있어야 한다. 리팩터링의 전제 조건이다.

보기 옵션

글자 크기 100%자간 0.00줄 간격 1.7