
339
Chapter 8
리팩터링과 기술 부채 관리
■ 모든 테스트를 통과할 것
■ 의도를 드러낼 것 (프로그래머에게 중요한 모든 의도를 명시)
■ 중복된 로직이 없을 것
■ 가능한 한 가장 적은 개수의 클래스와 메서드를 사용할 것 (이전 세 가지 규칙에 부합하지 않는 것은 제거 )
이러한 규칙을 방해하는 요소가 있다면
( 성급한 추상화, 불필요한 디자인 패턴, 설계 부재 )
,
더 간단하고 적합한 설계가 있는지 고려해 보세요. 팀원이나 동종 업계 종사자 혹은 인터넷
46
을 통해 의견을 나누는 것도 충분한 도움이 됩니다.
코드베이스 설계 원칙을 시스템 설계로 확장하기
지금까지 이 장에서는 단일 코드베이스의 맥락에서 설계 원칙, 코드 스멜 및 리팩터링에 대해 설명했지만 이
장에서 배운 내용은 업스트림 피처 스토어,
ML
훈련 파이프라인, 추론 서비스 및 데이터 제품과 같은
ML
솔
루션 구성 요소 간의 시스템 수준 상호작용에도 적용할 수 있습니다.
『
Machine Learning: The High-Interest Credit Card of Technical Debt
』(
O
’
Reilly
,
2020
)
에서 저자들은 경
계 침식, 얽힘, 선언되지 않은 소비자, 과도한 데이터 의존성, 죽은 실험 코드 경로, 파이프라인 정글 등 시스템
수준 기술 부채의
14
가지 사례를 열거합니다. ...