[개발자의 글쓰기] 2장. 개발 시간을 줄여주는 이름 짓기와 주석 쓰기

이 글은 "개발자의 글쓰기"를 읽고 좋은 구절들을 기록하거나 느낀 점을 기록하는 글입니다.

개발자의 글쓰기

 

1. 네이밍 컨벤션, 이유를 알고 쓰자

어떤 방법으로 이름을 정하던 중요한 것은 표기법 자체가 아니라 사용하는 이유다.

 

많은 컨벤션이 생긴 이유는 가독성과 개발자들 사이의 소통 때문이다.

 

어떤 방법이든 좋다. 같이 일하는 팀원들과 컨벤션을 정하고 지키도록 노력해보자

 

2. 변수 이름을 잘 짓는 법

책에서 알려주는 방법 중 한 가지 방법은 중요한 단어를 앞에 쓰라고 한다.

 

개발 도구가 단어를 검색하면 다 잘 찾아주기 때문에 크게 의미가 없을 수도 있지만
중요한 것이 앞에 와야 한다는 기본 원칙을 지키라고 한다.

 

함수 이름은 1함수 1 업무 규칙을 적용해라(하나의 함수에서 한 가지 일만 해라)

 

3. 좋은 이름의 기준, SMART

• Search (검색하기 쉽게)

에러 메세지의 이름을 작명한다고 할 때 예를 들어 접두어로 Error를 붙여서 작명하게 된다면
Error와 관련된 모든 것을 한 번에 찾을 수 있다.

 

하지만 같은 접두어를 많이 사용하게 된다면 오히려 역효과를 나타낼 수 있다.

그럴 땐 에러를 구분할 수 있는 체계부터 만들어야 한다.

 

꼭 접두어를 사용하라는 것은 아니다. 같이 개발하는 팀의 컨벤션에 맞게 사용하면 된다.

 

• Mix (조합하기 쉽게)

개발 언어의 문법과 조합해서 작명해라.
개발 언어 자체가 이미 이름에 대한 기본 체계를 갖고 있기 때문이다.

 

• easy to Agree (수긍하기 쉽게)

팀원들의 대부분이 수긍할 수 있는 이름이다. 그 상황에 맞는 이름이냐는 것이다.

 

• easy to Remember (기억하기 쉽게)

개발을 하다보면 엄청 많은 변수명을 만들게 된다.

이름에 따라 기억에 남는 이름도 있을 것이고 기억이 나지 않는 이름도 있을 것이다.

 

뇌는 감각적인 것을 좋아한다. 시청각적으로 기억에 잘 남도록 작명을 해보자

 

• easy to Type (입력하기 쉽게)

입력하기 쉬운지, 오타를 낼 가능성이 적은지 검토를 해보자

 

4. 좋은 코드에는 주석이 필요 없다?

보통 주석으로 코드에 대한 설명들을 적어둔다.

주석을 남긴다는 것은 변수명, 코드에 대한 이름을 다시 한번 생각해볼 필요가 있다는 것이다.

 

물론 주석이 필요 할 때도 있다.

각자의 생각이 달라서 이름을 보고 해석이 달라질 수 있기 때문이다.
그러므로 주석을 사용해서 실수를 줄일 수 있다.

 

주석은 무조건 나쁜 것이 아니다.

필요한 곳에 맞게 사용된다면 좋은 것이다.

 

5. 다른 개발자를 배려하는 주석 쓰기

주석이 반복된다면 틀린 주석일까? 아니다. 상황에 따라 다를 것이다.
예를 들어 코드를 처음부터 읽지 않고, 필요한 부분만 검색해서 보는 경우에는 중복된 주석이라도 필요하다.

무조건 반복되는 주석이라고 지워야 하는 것은 아니다.

 

주석도 코드다. 하지만 잘못 쓴 코드는 디버깅으로 수정할 수 있지만 잘못 쓴 주석은 디버깅으로 찾을 수 없다.

코드 리뷰를 하며 주석 리뷰도 꼼꼼히 하고, 불필요한 주석은 삭제하자.