Wrap-up: 이번 챕터에서 배운 핵심 내용
1. 코드는 '실행 가능한 요구사항 명세서'여야 합니다.
•
코드를 읽었을 때 비즈니스 로직(기획서의 내용)이 한눈에 들어와야 합니다.
•
"USD일 때는 이렇게, KRW일 때는 저렇게"라는 요구사항이 있다면, 코드에도 그 분기가 명확하게, 그대로 보이는 것이 좋습니다.
2. 섣부른 추상화(Premature Abstraction)를 경계하세요.
•
코드를 짧게 만들거나 중복을 없애는 것(DRY)에 너무 집착하면, 오히려 로직이 숨겨져 해석하기 어려워집니다.
•
모든 통화를 하나의 객체나 함수로 일반화하려 하기보다, switch-case 등을 사용해 각 통화별 특수성(계산식, 포맷팅 위치 등)을 드러내는 것이 유지보수에 유리할 때가 많습니다.
3. '유연함'은 '수정하기 쉬움'에서 옵니다.
•
만약 '호주 달러'에 대해서만 할인율이 달라지거나, ‘원화’에 대해서만 10원 미만 절사한다는 규칙이 생긴다면?
•
모든 로직이 꽁꽁 묶인 추상화된 코드보다, 케이스가 분리된 코드가 대응하기 훨씬 쉽습니다. '나중에 코드를 고칠 동료'를 배려하는 코드를 작성해 보세요.
액션 아이템
배운 내용을 실무에서 실제로 활용해보며 온전히 내 것으로 만들어봐요.
아래 예시를 참고하여 액션 아이템을 만들어 봅시다.
(예시) 오늘부터 해볼 것[코드 읽기] 현재 작업 중인 컴포넌트를 소리 내어 읽어보세요. "만약 A라면 B한다"는 기획 의도가 코드만 보고도 설명이 되나요?
[리팩토링] 지나치게 일반화되어 있어 수정할 때마다 여기저기 시선을 옮겨가며 확인해야 하는 '만능 함수'가 있다면, 차라리 그대로 풀어서 직관적으로 만들어볼 수 있을지 고민해 보세요.
오늘 공부 완료!
수고 많으셨습니다! 오늘 박문철 익힘책과 함께한 공부 재밌으셨나요?
익힘책을 풀어보며 느낀 점, 흥미로웠던 점, 혹은 다짐하고 싶은 것이 있다면 아래에 댓글로 남겨주세요!
익힘책 필진에게 해주고 싶으신 말씀이나 의견 또한 편하게 부탁드려요
