Clean Code "의미있는 네이밍"

Clean Code "의미있는 네이밍"

Clean Code 저서를 읽은 후 주관적인 내용을 많이 포함하고 있는 글이기 때문에 틀린 내용이나 생각이 다른 부분이 있다면 제안해주세요 :)

 

 

의미가 불분명한 불용어 사용을 자제하라

불용어(Noise word) - 큰 의미를 가지지 않아 검색엔진 색인에서 제외되는 단어

const userInfo = useSelector((state) => state.USER.data); // AS-IS
​
const user = useSelector((state) => state.USER.data); // TO-BE

Clean Code에서는 'Info', 'Data' 키워드를 대표적인 불용어로 꼽고 있다. 하지만 나의 경우 변수 네이밍에 'Data', 'Info' 키워드를 매우 즐겨 사용하곤 했던 것 같다. 특히 FE의 경우 데이타를 페칭해서 화면을 구성해나가기 때문에 거의 모든 프로젝트에서 이 두 가지의 키워드를 사용하지 않았던 적이 없었던 것 같다

위 코드는 실제로 한 프로젝트에서 내가 작성한 일부의 코드이다. 만약 'user', 'userInfo' 두 개의 변수가 있다면 그 의미를 분명히 구분하기가 힘들 것이다. 또한 'userInfo'가 아닌 'user'라는 네이밍만으로도 우리는 통상적으로 유저 정보가 들어있을 것이라고 쉽게 예상할 수 있을 것이다

const userInfoData = useSelector((s) => s.USER_INFO.data);
const userInfoLoading = useSelector((s) => s.USER_INFO.loading);
// AS-IS
​
const user = useSelector((s) => s.USER_INFO.data);
const userLoading = useSelector((s) => s.USER_INFO.loading);
// TO-BE

위 코드는 불용어가 더욱 불필요하게 사용된 경우다. 당시 나는 유저 정보와 유저 로딩 여부에 대한 상태값을 저장해두기 위해 이같은 변수 2개를 만들었을 것이다. 하지만 우리는 'Info', 'Data'와 같은 불용어를 사용하지 않고도 유저 정보와 로딩 여부를 저장하고 있다는 것을 쉽게 알아차릴 수 있다

 

const studentList = ['Anna', 'Jay', 'Rogers', 'Now'] // AS-IS
​
const students = ['Anna', 'Jay', 'Rogers', 'Now'] // TO-BE

'List' 키워드 또한 대표적으로 많이 사용했던 불용어 중 하나이다. 우리는 'studentList'처럼 불필요한 키워드를 쓰는 것보단 'students'와 같이 간편하게 복수형으로 쓸 수 있을 것이다

물론 불용어 사용을 무조건 기피할 수는 없다. 위의 'List' 키워드의 경우 자료구조적인 측면에서 구분하기 위해 사용되어야 하는 경우가 있을 것이다. 가령 학생정보를 List와 Set 두 가지의 자료구조로 저장하는 변수를 네이밍해야하는 경우에는 'studentList', 'studentSet'으로 지정해줄 수 있을 것이다

또 마이페이지와 같이 유저 정보 중 내 정보만을 저장하는 변수를 네이밍하는 경우에는 'myInfo'와 같이 이름을 지정하는 것이 간편할 것이다

 

 

검색하기 쉬운 이름을 사용하라

Clean Code 저서에서는 검색의 관점에서 길이가 긴 변수명이 짧은 변수명보다 낫다고 제안한다. 물론 긴 변수명을 가독성있게 지어내기 위해서는 꽤나 정성을 들여야 하는 것이 맞지만(이 점은 항상 염두에 두고 코드를 짜보자..!) 분명 프로젝트가 거대해지고 특정 코드를 찾아들어가는 경우에는 긴 변수명이 효과를 발휘할 수 있지 않을까 생각한다

또 책의 일부에서는 IDE를 적극 활용할 것을 제안하고 있다. 특히 불필요한 접두어의 사용을 피하라는 부분은 공감했다. 불필요한 접두어를 많은 변수에 사용하게되면 IDE 자동완성기능에서 너무 많은 변수가 탐색되어 효과적인 기능 활용이 어려울 것이다

 

Enum의 사용

Enum 문법의 경우 주로 상수 변수들의 추상화, 가독성을 위해 사용된다

const enum Language {
  Korean = 'ko',
  English = 'en',
  Japanese = 'ja',
  Spanish = 'es'
}
​
const currentLang = 'ja' // AS-IS
​
const currentLang: Language = Language.Japanese // TO-BE

위의 간단한 코드를 살펴보게 되면 Enum으로 상수 변수들을 추상화하여 우리는 상세한 상수 내용을 알고 있을 필요가 없을 뿐더러, IDE 자동완성 기능을 적극적으로 활용할 수 있게 된다. 즉, Enum의 활용을 통해 검색의 용이성, IDE의 활용도를 높일 수 있을 것이다

Enum은 개발자에게 편의성을 제공해 주는 문법이기는 하지만 타입스크립트 Enum 문법은 Rollup 번들러의 경우 Tree shaking이 되지 않는 문제를 유발하기도 한다. 물론 아래 포스트 글을 참조해보면 Webpack5에서는 IIFE와 관련한 Tree shaking을 유발하지 않는다고 하지만 이 경우도 Configuration에 따라 문제가 되기도 하는 것 같다

이러한 점에서 Typescript는 'const enum'을 제공하고 있다. 'const enum'은 쉽게 말해 트랜스파일 시 enum을 완전히 제거하고 그 자리에 해당하는 상수 프로퍼티로 변환되는 문법이다. 따라서 Tree shaking에 관한 문제는 이 문법으로 해결이 가능할 것이다 (물론 const enum이 최적의 해결방안이라고는 말할 수는 없다. const enum은 Babel로 트랜스파일될 수 없어 'babel-plugin-const-enum' 패키지를 설치해야 한다)

• LINE Engineering "Typescript enum을 사용하지 않는게 좋은 이유"
• Typescript, Enum 왜 쓰지 말아야하죠?

또 Enum을 사용할 때 팀원들 간 Enum 변수명은 어떤 표기법을 쓸지? 내부 프로퍼티는 무슨 표기법을 쓸지에 관해서도 통일해서 사용하는 것이 좋다

이렇듯 Enum을 사용하는데 있어서도 고려할 점이 꽤나 많아보인다. 코드는 정답이 있는 것이 아니기 때문에 팀 내에서 어떤 코딩 스타일을 문법을 사용할 것인지 잘 확립해두는 것이 가장 베스트가 아닐까 생각한다

 

 

불필요한 접두어, 접미어의 사용을 자제하자

Clean Code 본문에서는 많은 현대 개발자들이 이름을 해독하는 방식을 재빨리 터득함으로써 변수 네이밍에 접두어, 접미어를 사용하는 방식은 옛날 방식이 되어가고 있다고 소개한다. 물론 여기서 말하는 접두어, 접미어는 의미를 가지는 필수적인 단어가 아닌 불필요한 접두어, 접미어를 가리키는 것이다

최근 타입스크립트로 코딩을 하고 있는 입장에서 불필요한 접두어, 접미어 사용 자제는 꽤나 공감이 가는 부분이다

interface ITodoItem {
  
} // bad
​
interface TodoItemInterface {
  
} // bad
​
interface TodoItem {
  
} // good

실제로 Google typescript 스타일 가이드에서도 인터페이스에 'I'와 같은 접두어나 'Interface' 접미어를 되도록 사용하지 말라고 권고하고 있다. optional 인자에게 'opt_'와 같은 접두어의 사용 또한 사용하지 않을 것을 추천하고 있다. IDE의 발전으로 멤버 변수나 옵셔널 인자의 네이밍에 굳이 표시를 하지 않아도 우리는 글자 색상이나 자동완성기능을 통해 충분히 인식이 가능하기 때문이다

 

 

한 개념에 한 단어를 사용하라

FE 개발에서는 API 서버로부터 데이타를 받아와 렌더링을 진행하는 경우가 많다

따라서 데이타를 가져온다는 의미의 'get', 'fetch', 'retrieve' 단어들을 섞어서 사용한다면 혼란스러울 것이다

그래서 이 단어들의 명확한 의미를 찾아보니 미묘한 의미 차이가 있음을 알 수 있었다

• get - 단순히 '~을 가져오다'의 의미
• fetch - 대상이 있는 곳으로 가서 가져오다
• retrieve - 대상이 어디 있는지 모르는 상태에서 있는 곳을 찾아내 가져오다

그래서 통상적으로 API 호출을 통해 데이타를 얻어오는 경우에는 'fetch'를, 이 외의 데이타를 가져오는 경우에는 'get' 단어를 활용하면 의미에 혼동이 덜하지 않을까 생각한다. 혹은 팀 내에서 데이타를 가져오는 행위를 한 단어로만 통용하기로 정해두는 것도 방법이지 않을까 싶다

ref. IT 글쓰기와 번역 노트

 

 

부록) Airbnb 코딩 컨벤션 살펴보기

• Airbnb Javascript 스타일 가이드 번역본