나만의 이름 VS 모두의 이름
'개발자의 글쓰기'를 읽고
출처 : 인터넷 교보문고 (개발자의 글쓰기)개발자는 본업에서 가장 중요하다고 볼 수 있는 '코드'를 써야 하는 사람이다. 저자는 일반 글쓰기와 개발자가 써야 하는 글의 차이점을 시작으로 개발자의 글쓰기 가이드를 제시한다. 본인은 아직 주니어 개발자이기에, 신입의 기준에서 책을 읽으며 느낀 점을 정리해봤다.
구현에만 급급한 신입은 코드를 잘 못쓸 때가 많다 (물론 신입만이 아니다). 순간 떠오르는 단어를 조합으로 변수와 함수명을 지을 때가 많다. 또한, 어떤 때는 이렇게 다른 때는 저렇게 개성이 묻어 나오게 이름을 지을 때가 많다.
협업을 중시하는 현재 개발 문화에서 변수와 함수명을 작명하는 과정은 중요하다. 관련 있는 사람들이 내가 작성한 코드를 가지고 작업을 할 수 있는 환경에 노출되어있기 때문이다.
이러한 이유로 좋은 환경에서 개발을 진행해온 신입이라면 코드 리뷰를 받으며 이름을 다시 개명(?)하는 작업을 진행할 수 있다. 이를 통해 새로 태어난(?) 코드는 동료들이 받아들이기에 불편함이 없어 모두의 개발 시간을 줄여줄 수 있다.
그렇지 못한 개발자들은 본인만의 익숙해진 단어와 패턴의 조합으로 작명하는 방식이 정착될 수 있다. 남들이 보기에도 납득할 수 있는 작명을 짓는 방식이 자리 잡았다면 너무나도 좋을 것이다. 하지만 아쉽게도 자신만 이해할 수 있는 방식으로 자리 잡았다면 어떤 상황이 나타날까? (극단적인 상황을 만들어보자)
[동료]
이 함수는 뭐지?
(구현된 로직을 분석하며) 아... 이런 기능을 담당하는 함수구나.
헷갈리지 않게 임시로 표시해두자.
[나]
단어 조합만 봐도 이해할 수 있지 않나?
그냥 가져다 쓰면 되는데...
1차 원인 제공은 코드를 작성한 본인이 될 수 있다. 하지만 본인은 왜 이러한 작명법이 남들이 보기 힘들지 단번에 파악하기 힘들다. 이렇게 작명법에 대한 고민을 한 번쯤 해봤거나, 현재 이러한 고민을 하고 있는 개발자라면 가볍게 읽어보길 추천한다.
'어떤 사람은 이름을 지을 때 이런 식으로 접근하는구나!' 참고해 볼 법한 책으로 느꼈다. 물론, 본인의 일관성 있는 작명 습관이 더 중요하다. 하지만... 책 안에 정리된 내용들이 바이블은 아닐지라도 수많은 경험 속에 묻어있는 선배의 경험을 참고해볼 만하지는 않을까?
#글쓰기연구소 #글좀쓰자
