실용주의 프로그래머(20주년 기념판)
데이비드 토머스•앤드류 헌트
2장 - 실용주의 접근법 (~Topic 9)
ETC
좋은 설계는 나쁜설계보다 바꾸기 쉽다.
- 우리는 ETC 원칙을 따라야 한다. (Easier to Change) 바꾸기 쉽게!
- 결합도를 줄이는 이유도, 단일 책임 원칙도, 변수명명 법 모두 ETC를 위한 것이다.
ETC는 규칙이 아니라 가치
- 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극적으로 '바꾸기 쉬운' 방향으로 코드를 작성해라
- 여러가지 길 중에 선택을 하였다면, 현재 상황과 선택, 변경 사항에 대한 추측을 정리해두어라. 추후 변경에 큰 도움이 될 것
- 항상 생각해라, 저장할 때 테스트할 때 언제든 '이 코드는 바꾸기 쉬운가?'
DRY 원칙
중복의 해악
- 우리는 DRY 원칙을 따라야 한다. (Don't Repeat Yourself) 반복하지 마라.
- 지식(기술)은 변화한다. 규제든 기획의 변경이든 항상 우리는 유지보수 해야한다. 만약 DRY를 따르지 않는다면 똑같은 것은 두 군데 이상 표현될 것이고, 하나를 바꾸면 나머지도 바꿔야함을 기억해야 한다.
- DRY는 소스코드에 국한되지 않는다. 지식의 중복, 의도의 중복 또한 하지 말자.
모든 코드 중복이 지식의 중복은 아니다.
- 코드 내용이 아니라 의미와 사용을 보자.
- 가령 연령과 주문수량을 검증하는 코드가 있다면 두 가지의 내용이 완벽하게 동일하더라도 이는 DRY 위반이 아니다. 우연히 규칙이 같을 뿐, 이것은 우연이지 중복이 아니다.
- 변수명이나 코드를 통해 충분히 설명이 가능한 상황이라면 굳이 주석으로 문서화를 시키지 않는다. 추후 코드내용을 변경할 때 우리는 2군데(혹은 그 이상)을 수정해야 한다. 이는 DRY 위반
데이터의 DRY 위반
- 자료 구조는 지식을 표현한다.
- 가령 "선" 이라는 데이터를 저장하기 위해 우리는 시작값, 끝값, 길이를 저장한다고 하자. 우리는 시작값과 끝값으로만도 길이를 구할 수 있다. 이는 DRY위반이지만 때론 성능상의 이유로 이를 위반할 수 있다. 요령은 중복의 영향을 국소화 하는 것이다. 바깥세상에는 DRY원칙 위배를 노출하지 않되, 클래스 내의 메서드에서 이를 해결하면 된다.
- API와 연결할 때, 혹은 데이터를 받아올 때 리턴 되는 코드에 대한 작성이 두 군데 이상 사용된다. 이는 아에 피할 수 없지만 완화시킬 수 있다.
- 내부 API의 경우 언어와 기술에 중립적인 형식으로 정의하라. (Swagger, apach Thrift, google Protocol Buffer 등의 도구가 있다.)
- 외부 API의 경우 OpenAPI같은 형식으로 엄밀하게 문서화 하여라.
- 데이터 저장소와의 중복도 있다. 데이터를 객체로 옮기는 부분에서 유의해라. 상황에 따라서 고정된 구조가 아니라 키-값의 Map, Hash 등에 밀어 넣는게 유리할 때도 있다. (개인적인 생각으로는 이 부분이 조금 어렵다. Object를 버리고 Map을 쓰는게 맞는건가...) 다만 이 경우 안전장치를 위해 검증 도구를 가진 계층을 추가해야 할 것이다. (개인적인 생각으로는 여기서 검증도구가 요구되면 이것도 나름의 DRY라고 할 수 있지 않을까?)
개발자 간의 중복
- 우연히 똑같은 일을 해서 똑같은 코드를 작성할 수 있다. 이는 결국 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀으로 해결해야 한다. 다른 이가 당신의 코드를 건드린다고 기분 나빠하지 말아라.
댓글
댓글 쓰기