[주클] 주관적인 클린 코드 - 유비쿼터스 언어와 네이밍의 중요성

이 시리즈는 어떤 코드가 좋은 코드일까라는 질문에 답하기 위한 저의 주관 100%의 시리즈입니다.
제가 생각한 것이 정답이 아닐 확률이 높습니다.
여러분들이 생각했을 때 더 좋은 방법이 있다 하시면 댓글로 달아주세요!

 

제가 새로운 팀에서 업무를 진행하거나 다른 분의 코드를 새로 보면서 업무를 진행해야하는 상황에서 느낀 점은 함수명, 변수명 등, 이름을 잘 선택해야한다 입니다.

 

어느 회사에 처음 들어가서 새로운 코드를 봤습니다. aoc? dv? 이게 무슨 말일까요?

 

모든 회사, 모든 팀은 각자의 Ubiquitous Language(보편 언어)가 존재할 것입니다. 팀 내부에서 사용하는 특정 지칭어 혹은 의사소통을 편하게 하기 위한 줄임말들 같은 것들을 말합니다.

 

이미 익숙해져 있는 분들에게는 너무나 당연한 것들이고 새로 들어온 분들에게는 또 하나의 넘어야할 산입니다.

<가상의 스토리>
슨배님 : aoc는 *** 이런 말이고 dv는 device의 줄임말로 m-dv는 mobile device라는 뜻이고...
나 : ....
슨배님 : 저희가 업무에 사용하는 단어가 많이 달라서 설명이 좀 필요할 거 같아요. 업무 설명 회의를 10회 정도...
나 : ....

이렇듯 유비쿼터스 언어가 내부적으로 꼭 필요하지만 너무 복잡하다면 적응이 많이 어려울 수 있습니다. 그래서 적응하는데 시간도 오래걸리고 설명해주는 사람의 시간도 많이 뺏게 됩니다.

 

<유비쿼터스 언어가 어려울 때 단점>

• 신규 인원이 적응하기 어렵다.
  • 업무 설명에 시간이 많이 든다.
  • 적응 전까지 업무 효율이 떨어진다.
• 용어에 대한 설명이 누락됐을 때 유추가 어렵다.
• 단어의 의미가 명확해지지 않는다.

 

그래서 제가 생각했을 때는 보편언어는 사용하기에는 편하되 누가봐도 쉽게 이해할 수 있어야한다! 라고 생각하게 됐습니다.

주관적인 클린 코드 방법

유비쿼터스 언어와 네이밍은 굉장히 주관적인 부분입니다. 각 팀의 상황과 개인적으로 사용했을 때 편한것이 가장 중요합니다. 하지만 밑에서 추천하는 방법은 조금이라도 나중에 리소스를 덜 소비하도록 하는 방법을 생각해본 것입니다.

 

<Marrrang 룰>

• 줄임말은 최소화 한다.
• 문서화 되지 않은 유비쿼터스 언어는 사용하지 않는다.
• 함수명, 변수명에는 줄임말을 사용하지 않는다.
• 여러 의미를 포함하기 위한 단어를 만들지 않는다.
  • 포함할 수 있는 단어가 있다면 사용해도 좋지만 일부러 만들지는 않는다.
  • 단어가 분리되더라도 명확하게 사용하는 것이 좋다.
• 중복된 의미를 가진 단어는 하나를 사용하도록 정한다.
• 되도록 쉬운 영어단어를 사용한다. (모두가 알만한)
• 내용이 복잡해서 네이밍이 복잡해지는 함수는 주석으로 보조한다.
• get, search, show, add, modify 등 crud에 대한 동사는 각각을 하나로 정해서 사용한다.