읽기 좋은 코드를 도와줄 조언들
"추상과 구체를 넘나드는 것"
나무를 보는 눈과 숲을 보는 눈을 갖는 전문가스러운 초석을 만드는 과정
능동적 읽기
복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링 하면서 읽기
공백으로 단락 구분하기
메서드와 객체로 추상화 해보기
주석으로 이해한 내용 표기하며 읽기
눈으로만 읽는 코드는 이해하는 데 어려움이 있기 때문에 충분히 코드를 갖고 놀면서 이해 해보는 것을 추천한다.
또한, 언제든 원래 코드로 돌아갈 수 있는 git reset --hard 가 있다. 얼마든 망가져도 우린 돌이킬 수 있다.
이 능동적 읽기의 핵심은 수단과 방법을 가리지 않고 도메인 지식을 늘리고 이전 작성자의 의도를 파악하는 것이다.
오버 엔지니어링 경계
필요한 적정 수준보다 더 높은 수준의 엔지니어링
예시 1
구현체가 하나인 인터페이스
만약, 인터페이스 형태가 아키텍처 이해에 도움을 주거나 빠른 시일 내 구현체가 추가될 가능성이 있다면 납득 가능 -> 이 구조는 "스프링에서 자주 사용되는 Service - ServiceImpl" 과 비슷하다.
위 예시는 구현체를 수정할 때 마다 인터페이스도 수정해야 하며, 코드 탐색에 대한 깊이가 깊기 때문에 영향을 주며 어플리케이션이 비대해진다.
예시 2
너무 이른 추상화
너무 과도하거나 너무 이르면 정보 자체가 숨겨지기 때문에 복잡도가 높아진다.
후대 개발자들이 선대의 의도를 파악하기 어렵다.
오버 엔지니어링을 경계하고 꼭 필요한 곳에 알맞게 사용해야한다.
은탄환은 없다
클린 코드도 은탄환이 아니다.
📌 실무의 입장은 2가지 사이의 줄다리기이다.
지속 가능한 소프트웨어의 품질(클린코드) vs 기술 부채를 안고 가는 빠른 결과물
대부분의 회사는 돈을 벌고 성장해야 하고, 시장에서 빠르게 살아남는 것이 목표
이런 경우에도 클린코드를 추구하지 말라는 것이 아니라, 미래 시점에서 잘 고치도록 작성할 수 있는 코드 센스가 필요하다.
결국은, 클린 코드의 사고법을 기반으로 결정할 수 있는 것
확장 가능한 형태의 설계를 꾸준히 이어갈 수 있도록 TODO 작성하기 등
📌 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다.
당장 급하게 배포가 필요한데, 동료에게 스타일 관련 리뷰를 주고 고치도록 강요한다면?
이 사례는 클린 코드에만 입각해서 생각한 것 -> 회사의 입장에서는 의미가 없다.
📌 도구라는 것은 일단 그 것을 한계까지 사용할 줄 아는 사람이 그 것을 사용하지 말아야 할 때도 아는 법
적정 수준을 알기 위해 때로는 극단적으로 시도해보자.
오버 엔지니어링도 시도 해보고 몸으로 느끼며 적정 수준을 배우기
항상 정답인 기술은 없고, 특정 기술과 방법론을 연습할 땐 한계 까지 다다른 후 적정 수준을 깨닫기
Last updated