2022년 7월 7일 TIL - 적합한 이름 짓기라는 이름의 고통

 

이월 3주차의 종점을 향해 달려가고 있는 목요일, 주차를 진행하면서 느끼고 있는 가장 큰 화두는 클래스, 변수, 메서드의 '이름 짓기'이다.

 

 

나름 이름 짓기에 신경을 쓰고 있다고 생각했었다. x, a, b, c 이런 식의 한 글자 단어나 cnt, idx 같은 축약어를 쓰지 않으려 했고, 영단어 수준이나 문법이 허용하는 선에서 변수나 메서드의 역할도 의미가 드러나게끔 노력하고 있다고 생각했다. 아쉽게도 그 한 줌 있던 자부심은 주간 퀘스트를 수행하기 위해 작성한 소스코드에 트레이너님이 달아주신 리뷰를 보면서 산산조각나고 말았다. 수요일 오후에 리뷰를 확인하고 충격에 휩싸인 나머지 수요일 저녁에는 내가 어떤 단어나 표현을 쓰더라도 맞지 않는 표현을 쓴 것이라고 볼 수 있는 것 아닌가 하는 두려움에 휩싸여서 Todo List 프로그램 소스코드를 쉽사리 써내려가지 못했다.

 

스스로를 진정시키고 리뷰를 차근차근 읽어보았다. 다시 읽어보니 리뷰가 달린 이름 부분들이 그 이름만을 봤을 때 구체적으로 어떤 관심사를 위해 존재하는 것인지 바로바로 의미를 생각해내기 어려울 것이라는 점이 느껴졌다. 리뷰의 일부를 발췌한 내용은 다음과 같다.

 

 

toDo 인스턴스에 대해 state를 change하라는 의미를 가진 메서드명이다. 메서드명만 봐서는 state가 가리키는 게 뭔지, change는 어떤 방식을 통해 이루어지는 건지, 이를테면 정수값이 다른 정수값으로 바뀌는 건지 아니면 참/거짓 값이 바뀌는 건지를 짐작해내기 어렵다. 즉 메서드의 내용을 구체적으로 파악하기 위해 소스코드를 이리저리 찾아다녀야 할 것이기 때문에 소스코드를 읽는 데 과도한 인지자원이 들어가게 되고, 이는 소스코드의 가독성 저해로 이어지게 될 것이다.

 

 

 

'어떤 하나의 할 일' 객체를 정의하는 클래스명이다. To-do List의 to-do를 단순히 빌려와 클래스의 명칭으로 사용해도 괜찮지 않을까 생각해 사용했었다. 그러나 리뷰에 첨부해주신 To-do의 정의는 어떤 대상이라기보다는 가변적인 '상태'에 가까웠고, 따라서 상태가 변하게 된다면 그 이름으로 나타내는 객체의 정의가 변질될 수 있으므로, 객체의 이름에는 정말로 어떤 대상임을 나타낼 수 있는 이름을 주어야 한다는 점을 생각해보았다.

 

 

시간이 된다면 이름 짓기의 중요성과 과정을 정리한 포스트 글이 하나 있어 나중에 살펴볼 수 있으면 좋을 것이다. 그 전에, 이름을 짓는 데 있어 중요히 여겨야 할 지점을 스스로 먼저 고민해본다.

 

• 이름 지어지는 대상이 가져야 할 관심사가 무엇인지 파악한다. 관심사 외의 부분을 이름에 표현하는 것을 지양한다.
  • 이를테면, 객체의 메서드명을 지정할 때, 그 메서드가 객체의 어떤 것을 어떻게, 왜 바꾸는지에 집중해 의미를 부여한다. 핵심적인 행동 관심사 외에 그 객체나 행동을 표현하는 방식을 이름에 담지 않도록 주의한다. 표현 방식은 핵심적인 것이 아닌 언제든 다른 것으로 대체될 수 있는 부가적인 것이므로.
    
    
    
    

다행히도 나만 고통스러워하는 건 아닌 것 같고 많은 사람들이 고통스러워하는 부분인 것 같긴 하다. 경험이 쌓이다 보면 적응이 될까...?