9장: 코드 삭제의 미학
시간이나 노력을 들였기 때문에 어떤 것에 가치를 부여하는 것을 메몰 비용의 오류(sunk-cost fallacy)라고 합니다.
단 한 가지만 말하라면 바로 적은 것이 더 낫다
다음 시대는 코드를 지우는 시대일 것이다
우리는 아직 코드 삭제에 익숙하지 않는다 이것이 다음에 해결해야 할 큰 과제 라고 생각한다
복잡성을 제거하기 위한 코드 삭제
기능을 추가하고 테스트를 수행하며 다 많은 코너 케이스(복합 경계 조건)을 처리함에 따라 시간이 지날수록 성장하는 것이 바로 시스템 특징
- 도메인 복잡성: 도메인이 기본적으로 가지고 있는것
- 부수적 복잡성: 도메인이 요구하지 않았지만 우연히 추가된 모든 복잡성
경험 부족으로 인한 기술적 무지
기술적 우수성과 우수한 설계에 지속적으로 주의를 기울이면 민첩성이 향상된다
공동 프로그래밍 : 모든 아이디어가 코드에 적용되기 전에 다른 사람의 두뇌를 거쳐야 한다
시간 압박으로 인한 기술적 낭비
부수적 복잡성의 가장 단순한 유형은 기술적 낭비의 가장 일반적인것은 시간 압박에서 시작된다
환경에 따른 기술적 부채
기술부채는 일시적으로 차선의 해결책을 선택해서 이익을 얻는 것
성장에 따른 기술적 장애물
기술적 장애물(technical drag)dms roqkfdmf ejelrp aksemsms ahems rjt
사용하지 않으면 기능은 퇴화한다
친밀도에 따른 코드 분류
댄 노스는 약 6주가 지나면 코드가 알 수 없는 범주로 빠르게 이동하면서 해당 코드와 친밀도가 떨어지기 시작한다고 사례를 들어 주장함
유지 시간의 한계가 몇 개월이 아닌 몇주 단위여야 한다
레거시 시스템에서의 코드 삭제
레거시 코드의 일반적인 정의는 수정하기가 겁나는 코드(서커스 팩터 circus factor 의 결과)이다
스트랭글러 무화과나무 패턴
숙주는 레거시 시스템
코드 개선을 위한 스트랭글러 무화과나무 패턴 사용
호출의 빈도는 일반적으로 그것이 얼마나 중요한지를 나타내는 좋은 지표
동결된 프로젝트에서 코드 삭제
코드에는 사용하지 않는 다는 표시가 없어서 변경할때 마다 고려하고 유지 해야 한다
바람직한 결과를 기본값으로 설정
유지기간을 정해 놓고 그 기간이 지나면 코드를 삭제한다
스파이크와 스태빌라이즈(안정화)로 낭비 줄이기
빠르게 구현하고 코드를 얼마나 사용하는지 측정하고 사용하면 유지하고 사용하지 않으면 삭제한다
버전 관리에서 브랜치 삭제
브랜치는 시간이 지나면 축적되는데 이것은 불필요한 복잡성을 추가한다
브랜치 제한으로 낭비 최소화
협업 방법인 칸반을 적용할수 있다
코드 문서 삭제
문서는 정확히 3가지 조건을 충족해야 함
- 관련성
- 정확성
- 발견 가능성
지식을 문서화하는 방법을 결정하는 알고리즘
문서화하는 것이 의미가 있는지 여부 결정
- 문서화 대상이 자주 바뀌지 않는지
- 드물게 사용하는 경우 문서화
- 자동화 할수 있음 자동화
- 아니면 외워라
테스트 코드 삭제
낙관적 테스트 삭제
항상 참인 것은 삭제 해라
비관적 테스트 삭제
항상 거짓인 것은 삭제 해라
불안정 테스트 수정 또는 삭제
성공 실패를 반복하면서 예측할수 없는 테스트(불안정 테스트)는 삭제해라
복잡한 테스트를 제거하기 위한 코드 리팩터링
테스트를 리팩터링해야 한다는 것은 테스트 중인 코드에 적절한 아키텍처가 없다는 것
속도를 높이는 테스트 문화
느린 테스트와 빠른 테스트를 구분하고 가능한 자주 빠른 테스트를 진행하라
설정 코드 삭제
완벽하게 만들 수 없다면 최소한 설정이 가능하게 만들어라
설정의 예상 수명으로 범위 지정
- 실험을 위한 설정 : 베타 테스트 또는 A/B 테스트
- 과도기 적인 설정 : 릴리즈와 뱊호를 연결하는 것
- 영구적인 설정 : 사용량을 증가시키거나 유지보수가 간편해야 하기 때문에 특별하다
라이브러리 제거를 위한 코드 삭제
라이브러리를 사용하는것은 양날의 검
외부 라이브러리에 대한 의존도 제한
고통스러울수록 더 시도하라
작동 중인 기능에서 코드 삭제
코드는 부채이다 코드를 삭제하면 부채를 감소시킬수 있다