TIL
범위
- 실용주의 접근법 - 중복의 해악
기억하고 싶은 내용
프로그래머로서 우리는 지식을 수집하고, 조직하고, 유지하며, 통제한다. 우리는 명세서에 지식을 문서화하고 실행 코드에서 그 지식이 생명을 갖고 살아나도록 한다. _65p
불행히도 지식은 고정적이지 않다. …이러한 모든 불안정성은 우리가 소위 유지보수 모드에서 시스템에 대한 지식을 재조직하고 재표현하는 데 대부분의 시간을 보내게 되리라는 것을 의미한다. _65p
대부분의 사람들은 유지보수가 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 애플리케이션이 춠되었을 때 비로소 유지보수가 시작된다고 믿는다. 우리는 이들이 틀렸다고 생각한다. _65p
소프트웨어를 신뢰성 높게 개발하고, 개발을 이해하고 유지보수하기 쉽게 만드는 유일한 길은 우리가 DRY 원칙이라고 부르는 것을 따르는 것뿐이라 생각한다. _66p
DRY - 반복하지 마라 Don’t Repeat Yourself _66p
만약 하나를 바꾼다면 나머지 것들도 바꿔야 함을 기억해야 한다. 이것은 기억하느냐 마느냐의 문제가 아니다. 단지 언제 잊어버릴 것인가 하는 문제다. _66p
DRY 원칙은 낮은 차원의 지식은 그것이 속하는 코드에 놔두고, 주석은 다른 높은 차원의 설명을 위해 아껴두라고 말한다. _68p
문서를 작성하고 나서 코드를 작성한다. 뭔가가 바뀌면, 문서를 수정하고 코드를 갱신한다. …긴박한 시기가 되면 문서의 갱신을 뒤로 미루기 쉽다는 것을 안다. _69p
때때로 중복은 설계 실수의 결과롤 나타나기도 한다. …복수의 상호의존적인 데이터 요소들이 있을 경우 생기는, 약간은 덜 분명한 종류의 비정규화된 데이터가 있다. _71p
모든 프로젝트는 시간의 압박을 받는다. …이런 유혹을 느낀다면 ‘돌아가는 것이 지름길이다'라는 진부한 격언을 기억하라. _73p
개발자간의 중복 - …분명한 책임 영역으로 나뉘어지지 않는 공통 필요 기능이나 데이터는 여러 번 거듭 구현될 가능성이 있다.
최선책은 개발자간에 적극적이고 빈번한 소통을 장려하는 것이다. _74p
재사용하기 쉽게 만들라. _74p
소감
어떻게 중복이 생기는가, 왜 중복을 그토록 피해야하는지, 중복이 생겼을 떄 어떻게 해결할 수 있는지 배울 수 있는 챕터였다. 실제 업무에서 생기는 ‘어쩔 수 없는' 중복은 ‘있으니까'라고 생각했던 안일한 생각이 완전 털려버린 기분이다. 실제로 다시 그 상황을 겪게 된다고 해도 이 방법으로 해결할 수 있을지 의문이 들기는 한다.
방법에 의문이 생기기보다는 시간, 상황의 압박 속에서 ‘돌아가는 것이 지름길이다'를 떠올릴 수 있을까하는 마음에 가깝다. 결국 중복은 자기합리화와 핑계일 수 밖에 없겠지만.
나중에 이해하고 싶은 부분
::TODO::
바깥의 DRY 원칙의 위배가 노출되지 않고, 단지 크래스 내의 메서들만이 좀 고생하면 된다. _72p
가능한 곳에서는 언제나 객체의 속성을 읽고 쓸 수 있는 액세스 함수를 사용하라. 그러면 캐싱과 같은 기능을 나중에 추가하기가 더 쉬워질 것이다. _72p
