[Clean-Code] 클린코드 제안서

( 이 글은 어떤 프로젝트를 리팩토링 하기 위해 투입되어 팀원들을 설득하기 위해 적은 글입니다. )

 

🧼 Beautiful is better than ugly.

들어가며

python을 켜고 import this 를 실행하면 첫 문장으로 이런 구절이 나옵니다.

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
...

아무래도 예쁜 게 좋겠죠? 😊

 

 

클린 코드

❓ 왜 클린 코드인가.

• 개발하면서 코드를 쓰는 시간 보다 읽는 시간이 훨씬 많다.
• 개발자는 결국은 코드로 소통해야 한다.
  • 내가 두달동안 어디 다녀와서 다시 복귀했을 때, 이 코드가 어떤 코드인지 설명할 수 있어야 함.
  • 내가 구현하진 않았지만, 상대방이 어떤 맥락에서 이렇게 구현한 것인지 이해할 수 있어야 함.
  • 이걸 포폴로 쓸 계획이라면 취뽀할때까지 시간이 얼마가 흘러도 알아볼 수 있는 코드여야 유리합니다..
• 개인적으로 생각하는 좋은 코드
  • 1순위 : 설명이 필요 없는 코드
  • 2순위 : 설명할 수 있는 코드

 

 

어떻게 클린 코드를 유지할 것인가?

 

깨진 유리창 이론

깨진 유리창의 법칙

코드 어딘가에서 냄새가 나기 시작하면 거기에 냄새를 하나 더 얹는 것 쯤은 이상하지 않게 됩니다.

그런 코드가 하나 둘 모여 결국 전체적으로 손쓸 수 없는 지경에 이르는 경우가 많습니다.

깨끗한 코드를 유지하기 위해 사소한 것 부터 다같이 개선할 수 있도록 노력해야합니다.

 

불필요한 코드 삭제

• 쓸모없는 주석 삭제
  • 주석은 없는 편이 제일 좋고, 주석으로 설명할 수 있는 코드는 최대한 코드로 설명해봅시다.
  • 진짜로 정말로 주석이 꼭 필요하다면 남겨둡니다. (예 : // TODO 등)
• 꼭 필요한 코드만 남겨두고 모두 삭제합니다.
• 주석처리된 쓸모없는 코드는 삭제합니다.
• console.log() 같은 개발을 위해 남겨둔 로그성 코드는 커밋 전에 모두 삭제합니다.
• 주석으로 코드를 설명할 수 있다면 그 주석을 지우고 코드로 설명할 수 있도록 변수명/함수명을 바꿔봅시다.

 

가독성

• 변수명 / 함수명은 많이많이많이많이 고민해보고 코드리뷰로 또 함께 고민해봅시다.
  • 신문 기사 제목만 보고 흐름을 알 수 있듯, 코드도 눈으로 훑으면서 이해할 수 있을만큼의 가독성을 지녀야 합니다.
• 디렉토리 구조는 한 눈에 알아볼 수 있어야 합니다.
  • 어디에 뭐가 있는지 찾느라 시간을 낭비하면 아깝잖아요~ 개발자는 시간이 비용입니다.
  • 디렉토리는 소문자, 컴포넌트는 대문자로 시작하여 구분하는 것이 좋습니다.
• 알 수 없는 상수는 따로 빼서 관리합니다.
  • 상수는 따로 constants 등의 디렉토리나 폴더를 만들어서 따로 관리합니다.
  • 주로 대문자를 씁니다. (예시 : const PAGE_NUMBER = 1 등)

• 상대경로 대신 절대경로를 쓴다.
  • 구조를 변경할 일이 생겨서 파일을 이동하면 다 깨지기 때문.
  • 알아보기에도 훨씬 쉽습니다. 상대경로는 깊이가 깊어질수록 알아보기 힘듦.

 

코드리뷰

👬 좋은 코드 리뷰 문화를 통해 서로의 코드에 대해 공동의 책임을 가지게 됩니다. 내가 구현하지 않았더라도 어떤 맥락에서 나온 코드인지 이해하고 있는 편이 좋습니다.

• 보다 상세한 코드리뷰를 받기 위해 PR을 상세히 남기는 것이 좋습니다.
• 프론트는 PR을 올릴 때 구현한 부분을 캡쳐하여 함께 올리는 것이 더 좋습니다.
  • 스토리북이 있다면 이 부분을 생략해도 괜찮겠죠?
• 안좋은 코드 리뷰의 예 :

• 이왕이면 커밋별로 코드를 순서대로 보는 것이 좋습니다.
  • 코드를 작성하는 사람도 보는 사람을 고려하여 커밋을 관리할 필요성이 생깁니다.
  • 어떤 흐름으로 작성하게 되었는지를 이해할 수 있습니다. (어떤 삽질을 했는지..?)
• 코드리뷰 시, 개선이 필요한 부분에 대해서는 거침없이 남기되, 막연히 별로라고 하기 보다는 어떻게 개선하면 좋을지 함께 적어주는 것이 좋습니다. 만약 개선점은 딱히 잘 모르겠지만 일단 이게 냄새가 난다는 것만 알겠다면 함께 고민해보자고 적고 같이 고민해봅시다.
• 아래는 코드리뷰 시 코멘트를 달게 되는 흔한 상황들 중 일부입니다.
  • 이보다 더 나은 변수명/함수명이 있다?
  • 로직을 이렇게 하면 좀 더 효율적이고 깔끔할 것 같다?
  • 이 부분은 어떤 것을 의도한 것인지 잘 모르겠다?
  • 이 부분에 주석/오타/로그가 남아있는 것 같다?

 

 

테스트 코드

• Jest / mocha 등 이용
  • E2E Test
  • Unit Test
• 테스트를 붙이면 코드를 보다 더 신뢰할 수 있고, 유지 보수가 수월해집니다.
• Given-When-Then 순으로 작성합니다.
  • Given : 주어진 데이터들로 (data 등을 mocking)
  • When : 어떤 케이스일 때 (조건)
  • Then : 어떤 결과가 나와야 한다.
• 어떤 것을 테스트해야할까?
  • 어떤 것을 입력했을 때, 어떤 결과가 나오는지에 대해 테스트
  • if 문이 있다면 그것을 기준으로 여러 테스트를 작성할 수 있다.
  • 성공테스트와 실패테스트를 나눠서 작성한다.

 

 

참고자료

Clean Code(클린 코드) - 교보문고

Clean Code(클린 코드) - 교보문고