[ whistle ] 불확실한 변수명과 클래스명의 위험성

오늘의 이슈

---

 취업 후 다른 프로젝트를 진행하다가 오랜만에 whistle project로 복귀하였는데요, 변수명과 클래스명이 생소하여 프로젝트 코드를 분석하고 이해하는 것에 많은 시간을 할애하게 되었습니다. 오늘은 변수명과 클래스명을 지을 때 어떻게 지어야 하는지, 왜 그렇게 지어야 하는지에 대해서 이야기 해보려 합니다. 

 

 제가 코드분석을 진행하면서 가장 어려움을 겪었던 부분은 "잘못된 의미의 도메인 이름을 사용한 것"이 었습니다.

 예를 들어, AS-IS 도메인 중 "team_list" 라는 도메인이 있었는데요 이 도메인은 팀원 목록을 다루는 도메인이었습니다.

 프로젝트 초기 설계 당시에 "team_list"라고 작성한 이유는 특정한 팀(team)을 다루는 리스트(list)이기 때문에 "team_list"라고 작성하는 것이 맞다고 판단하였는데요, 하지만 영어 문법에 맞게 "team_list"를 해석한다면, 여러 팀들이 들어가있는 하나의 목록으로 오해할 여지가 있습니다. 즉, 팀(team)+목록(list)이라는 국어식 어순을 영어에 적용한 것이 잘못된 변수명을 작성하게된 배경이 된 셈입니다. 따라서 "team_member_list"또는 "squad"와 같이 좀 더 명확한 의미의 단어를 사용해야 합니다.

 

해결방안

---

 클린코드 관점에서 볼 때 가장 기본이 되는 것은 명확한 의미를 가진 단어 선택입니다. 모호한 단어를 활용하게 된다면 프로젝트를 기획하고 설계한 당사자는 내재적 의미를 판단 할 수 있지만 그렇지 않은 경우에 완전히 다른 도메인을 만들 수 있기 때문입니다.

 따라서 솔로 프로젝트나 팀 프로젝트를 진행할 때 항상 협업의 여지를 고민하며 프로그래밍해야 한다는 것을 명심해야 합니다. 만약 개발자가 평생 동안 1인 개발자로 활동하며 솔로 프로젝트를 진행하는 것을 원한다면 불필요한 고민일 수 있겠지만, 그렇지 않다면 내가 만드는 코드를 언젠가는 다른 사람이 이어받아 지속적으로 유지보수 할 수 있다는 것을 기억해야 합니다. 

 변수명 또는 클래스명을 지을 때 두 가지 원칙을 준수하면 더 좋은 코드를 만들 수 있습니다.

1. 널리 사용하는 단어를 사용하자
   1. 고급진 언어일수록 생소하고 어렵습니다. 청산별곡에 쓰여진 내용보다 어릴적 배운 뽀뽀뽀의 가사가 훨씬 배우기 쉬웠던 것처럼 쉽고 단조로운 언어를 사용하는 것이 좋습니다.
2. 2음절 이상의 단어는 지양하자
   1.  두마디의 말보다 한마디로 말하는 것이 더 편한 것처럼 가급적이면 한 단어로된 익숙한 단어를 선택하는 것이 좋습니다. (사실은 DB명에는 띄어쓰기마다 언더바(_)를 사용해야하는데 이것이 은근 불편감을 줍니다.) 

 

 

오늘의 교훈

---

 의미를 명확하게 이해하지 못하고 코딩을 진행한다면 의도한 것과는 다른 결과물이 생성될 수 있다.