읽기 좋은 코드를 도와줄 조언들

"추상과 구체를 넘나드는 것"

나무를 보는 눈과 숲을 보는 눈을 갖는 전문가스러운 초석을 만드는 과정

능동적 읽기

---

복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링 하면서 읽기

• 공백으로 단락 구분하기

• 메서드와 객체로 추상화 해보기

• 주석으로 이해한 내용 표기하며 읽기

눈으로만 읽는 코드는 이해하는 데 어려움이 있기 때문에 충분히 코드를 갖고 놀면서 이해 해보는 것을 추천한다.

또한, 언제든 원래 코드로 돌아갈 수 있는 git reset --hard 가 있다. 얼마든 망가져도 우린 돌이킬 수 있다.

이 능동적 읽기의 핵심은 수단과 방법을 가리지 않고 도메인 지식을 늘리고 이전 작성자의 의도를 파악하는 것이다.

오버 엔지니어링 경계

---

필요한 적정 수준보다 더 높은 수준의 엔지니어링

• 예시 1

  • 구현체가 하나인 인터페이스

  • 만약, 인터페이스 형태가 아키텍처 이해에 도움을 주거나 빠른 시일 내 구현체가 추가될 가능성이 있다면 납득 가능 -> 이 구조는 "스프링에서 자주 사용되는 Service - ServiceImpl" 과 비슷하다.

  • 위 예시는 구현체를 수정할 때 마다 인터페이스도 수정해야 하며, 코드 탐색에 대한 깊이가 깊기 때문에 영향을 주며 어플리케이션이 비대해진다.

• 예시 2

  • 너무 이른 추상화

  • 너무 과도하거나 너무 이르면 정보 자체가 숨겨지기 때문에 복잡도가 높아진다.

  • 후대 개발자들이 선대의 의도를 파악하기 어렵다.

오버 엔지니어링을 경계하고 꼭 필요한 곳에 알맞게 사용해야한다.

은탄환은 없다

---

클린 코드도 은탄환이 아니다.

📌 실무의 입장은 2가지 사이의 줄다리기이다.

• 지속 가능한 소프트웨어의 품질(클린코드) vs 기술 부채를 안고 가는 빠른 결과물

  • 대부분의 회사는 돈을 벌고 성장해야 하고, 시장에서 빠르게 살아남는 것이 목표

이런 경우에도 클린코드를 추구하지 말라는 것이 아니라, 미래 시점에서 잘 고치도록 작성할 수 있는 코드 센스가 필요하다.

결국은, 클린 코드의 사고법을 기반으로 결정할 수 있는 것

• 확장 가능한 형태의 설계를 꾸준히 이어갈 수 있도록 TODO 작성하기 등

📌 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다.

• 당장 급하게 배포가 필요한데, 동료에게 스타일 관련 리뷰를 주고 고치도록 강요한다면?

• 이 사례는 클린 코드에만 입각해서 생각한 것 -> 회사의 입장에서는 의미가 없다.

📌 도구라는 것은 일단 그 것을 한계까지 사용할 줄 아는 사람이 그 것을 사용하지 말아야 할 때도 아는 법

• 적정 수준을 알기 위해 때로는 극단적으로 시도해보자.

• 오버 엔지니어링도 시도 해보고 몸으로 느끼며 적정 수준을 배우기

항상 정답인 기술은 없고, 특정 기술과 방법론을 연습할 땐 한계 까지 다다른 후 적정 수준을 깨닫기