[실용주의 프로그래머] 2장_실용주의 접근법 🌟

szlee·2022년 5월 20일
0



🔨 좋은 설계의 핵심

ETC
잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. 그래서 우리는 ETC(Easier To Change) 원칙을 따른다.

결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다.
단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다.
이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다.

교체 가능하게 작성 = 코드의 결합도를 낮추고 응집도를 높여라.

DRY
DRY(Don't Repeat Yourself)를 따르지 않으면 똑같은 것이 두 군데 이상에 표현될 것이다.
반복하지 말라. 하나를 바꾸면 나머지도 바꿔야 함을 기억해야 한다.

똑같은 개념을 다른 곳 두군데에서 표현하면 안된다.
그러나, 모든 코드 중복이 지식의 중복은 아니다.
코드는 동일하지만 두 함수가 표현하는 지식이 다를 수 있다. 두 함수는 각각 서로 다른 것을 검증하고 있지만 우연히 규칙이 같은 것뿐일 수 있다.

코드에 주석을 달면 시간이 지남에 따라 주석과 코드의 내용이 서로 어긋나게 된다. 함수의 이름으로 함수가 하는 일을 알려줘라.

변경에 용이하려면 우선 변경 작업을 할 코드를 읽기 쉬워야(좋은 이름, 내용과 일치하는 주석) 하고, 이 작업의 영향도를 판단하기 쉬워야 한다(똑같은 개념이 다른 곳에 없음, 낮은 결합도).

주석의 경우는 조금 애매한 것 같다. 물론 주석을 지양하고 주석이 표현하는 내용과 완벽히 맞아야 하므로 내용이 자주 바뀌면 관리가 어려운데 주석이 없다면 이해하기 어려운 로직이 분명 현업에 존재하기 때문이다.

'특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?-하나여야 한다.'
이렇게 '단 하나'가 현업에서 완벽하게 가능한가도 의문이 든다.

가독성과 DRY 중 선택을 해야하는 경우, 어떤 것을 선택해야할까?
개발을 하다가 반복을 피하면 가독성이 떨어지는 경우가 생겼는데 결국 반복이 한군데에서 일어나기 때문에 가독성을 선택했던 경험이 있다. 무엇이 더 좋은 선택이었을지는 아직 모르겠다.🤔







🧨 예광탄

어둠 속에서 빛을 내는 코드
시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.
예광탄 코드 : 기능은 별로 없지만 완결된 코드. 최종 시스템 골격 중 일부가 된다.

MVP. 즉 메인 기능을 먼저 만들고 살을 붙여가기.





profile
🌱

0개의 댓글