준용할 수 있는 변수명을 사용하기

프로젝트를 진행하면서 새로운 변수 작명 방법에 대한 이야기를 들었다.

기존에는 최대한 해당 변수를 명확하게 설명하려고 풀어쓰는 편이었다.

 

하지만 내부적으로 사용하는 고유단어가 많은 환경에서는 이런 방식은 독이 된다고 한다.

즉, 프로그램을 외부의 누군가를 위해서 만드는 것이 아니라 회사 내부에서 사용하려고 할 때 이런 경우가 발생한다.

 

전문성이 있는 경우가 특히 그렇다.

예를 들어서, 의료 관련 프로그램을 만든다고 해보자.

 

의학 용어는 어떤 단어가 무슨 뜻이라고 명확하게 정의가 되어 있다.

우리가 생각하듯 대충 감기, 몸살 이런 식으로 포괄적으로 표기할 수 있는 방식을 사용하지 않는 것이다.

해당 상황에 맞는 명확하고, 이미 결정된 단어를 사용해야만 하는 것이다.

구구절절 상황을 풀어쓰고 and, or를 붙여가면서 변수명을 작성하지 않는 것이다.

 

그런 경우에 해당 용어를 명확하게 알고 적으면 된다.

문제는 그런 용어를 포괄적으로 표현해야만 하는 경우에는 어떻게 변수명을 적을까?

 

풀어서 쓰는 것은, 이미 고유한 단어를 사용하는 영역이므로 불가능.

고유한 단어를 AND, OR 이런 식으로 붙여서 쓰기에는 너무 길고, 그 개수가 많아지면 사실상 불가능에 가까움.

 

그렇다면 고유한 단어를 포괄할 수 있는 단어 선택이 필요한데, 이걸 준용할 수 있는 변수명이라고 한다.

어떻게 짓는지 보았더니 대체적으로 몇 가지 패턴이 보였다.

 

 

1. 실제로 사용하는 사람이 인지하고 있는 단어로 치환하기.

2. 묶어야 하는 단어 중 대표 단어 하나로 엮기.

3. 실제로 정의된 상위 카테고리 이름을 사용하기.

 

 

3번이 가장 합리적으로 보여서 그렇게 하려고 했으나...

문제는 전문지식이 없는 분야의 고유한 단어를 묶는 상위 개념의 단어가 뭔지 하나하나 찾는 것은 너무나 비효율적이었다.

 

다른 분들을 보니 대부분 1번을 사용하고 있었다.

데이터베이스에 저장된 이름과 다르게 실제로 의사나 간호사가 인지하고 있는 단어는 다른 경우가 많았다.

코드명으로 기억하는 경우도 많았다.

그런 경우에는 UI에서 확인할 수 있는 해당 단어로 치환하여 묶어버렸다.

 

2번도 조금 보였다.

대부분 경우의 수를 따라서 yes면 a, no면 b, etc면 c 등 이런 식으로 갈래로 나뉘는데 결국 보면 a가 9할 이상의 빈도를 차지하고 나머지는 예외를 상정한 것에 불과한 경우가 많았다.

하지만 이 방법은 적절하지 않은 것이 명확하다...

실제로 다른 사람의 코드를 보면 왜 이게 이런 변수명이 되었지? 같은 생각이 들곤 한다.

물론 코드를 들여다보면서 이해도가 높아지면 아 저래도 별 문제가 없겠구나 그런 생각이 들긴 하는데...

직관적이진 않다.

 

 

여러모로 클린코드에서 제시한 명확하고 정확한 변수 작명법이 최고라고 생각했다.

하지만 분야에 따라서 해당 작명법이 매우 불편할수도 있다는 생각이 들었다.