[Book] 읽기 좋은 코드가 좋은 코드다

소스 리팩토링을 진행하면서 좋은 소스코드를 만든다는 것은 무엇일까에 대한 의문이 생겼다.

나 같은 주니어 개발자에게 좋은 가이드를 해주는 책인 것 같다. 매번 고민하던 네이밍이나 주석에 관하여 명확하게 기준을 얻을 수 있었다.

다음 주 면접이 끝나면 빠르게 다 읽고 리뷰를 마저 작성해야겠다.!

 

 

코드는 이해하기 쉬워야 한다.

• 코드를 더 좋게 만드는 것은 무조건적인 간결함이 아니다.
• 가독성의 기본 원리
• 코드는 다른 사람이 이해하는데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.
• 일회용으로 작성한 대충 쓴 코드가 어느 다른 프로젝트에 쓰일 수 있다.
• 분량이 적으면 항상 더 좋은가?
• 라인 수가 적은 것은 좋은 목표지만.. 이해를 위한 시간을 최소화하는 게 더 좋은 목표다!
• 이해를 위한 시간은 다른 목표와 충돌하는가?
• 정리되지않은 소스를 고치고 싶을 때 자문자답해보자
• 이 코드는 이해하기 쉬운가? 그렇다면 정리를 건너뛰어도 별 상관이 없다
• 어려운 부분
• 코드를 읽고 이해하기 쉬운지 따져보려면 추가적인 시간과 노력이 필수적이다.

이름에 정보 담기

• 특정한 단어 고르기 (무의미한 단어를 피하자)
• 재치 있는 이름보다 명확하고 간결한 이름이 더 좋다
• 보편적인 이름 피하기(혹은 언제 그런 이름을 사용해야 하는지 깨닫기)
• tmp나 retval 같은 보편적인 이름 피하자. 개체의 값이나 목적을 설명하는 이름으로 설정하기
• tmp라는 이름은 대상이 임시로 존재하면서 임시적 존재 자체가 변수의 가장 중요한 용도일 때에 한해서 사용하기
• 루프 반복자의 경우 i, j, k 보다는 member_i, lecture_j, school_k 로 표현한다면 더 명확하게 이해할 수 있다.
• 추상적인 이름 대신 구체적인 이름 사용하기
• 예제가 뭔 소린지 모르겠다.. 다시 읽기 🤔!
• 접두사 혹은 접미사로 이름에 추가적인 정보 덧붙이기
• 16진수의 id 값이라면 변수 선언시 hexId가 더 좋은 표현이다. 
• 단위를 포함하는 값들의 경우 덧붙여서 네이밍 해주자.

• 다른 중요한 속성 포함하기

• 이름이 얼마나 길어져도 좋은지 결정하기
• 추가적인 정보를 다믈 수 있게 이름 구성하기