[클린 코드 2장] 의미 있는 이름이 제일 어렵다

과거에 내가 의미 있는 이름이라고 착각했던 것들

 

[CASE_1]
const userList = await userRepo.findAll();

[CASE_2]
const result = await uRepo.findAll();

 

 

[CASE_1]의 문제점

 

• 반환되는 데이터의 타입을 변수명에 넣은것

 

[CASE_2]의 문제점

 

• result라는 변수명으로 어떤 데이터인지 추측하기 어려움
• uRepo또한 u가 무엇을 의미하는지 생각해봐야함

 

개선

const users = await userRepogitory.findAll();

• users로 여러명의 유저가 반환된다는 정보를 줄 수 있음
• uRepo -> userRepogitory로 변경함으로 누구나 예측할 수 있음

 

 

나쁜 이름으로 고생한 경험

 

예전 기업부설 연구소에서 신입 프론트엔드 개발자로 일할 당시 변수명이 aa인 경우와 bb인 경우를 종종 보았다.

주석 조차 존재하지 않는 전혀 예측할 수 없는 코드들로 반환되는 값들을 하나하나 확인하면 수정했던 끔찍한 경험..

정말 지옥이였다. 똥 같은 코드에 음식물같은 이름들을 하나하나 추가하여 개선하려해도 다른 개발자들이 보기에는 결국  똥같은 코드이다.

거기에 그 많은 변수명의 수정과 그 과정에서 발생하는 에러사항 그리고 수정하는데 걸리는 시간을 윗선(높으신 비개발직군)에서는 이해하기 힘든 작업이기 때문에 코드 리펙토링 작업을 수행하는것조차 쉽지 않다. 몰래몰래 조금씩 시간을 들여가면 바꾸거나 개인 시간을 사용하여 바꾸는 수 밖에 없는것이다.

결국 나도 그 레거시 코드들을 바꾸는것을 포기하며 매일매일 제발 오류가 없길... 하며 빌었던 경험이 있다.

그 많은 레거시 코드의 변수명을 다 리펙토링하는건 ... 새로운 코드를 생성하는것보다 더 힘들지도 모르겠다.

 

 

책을 읽으며 공감했던 부분과 공감하지 못한 부분

 

공감했던 부분

 

변수명이 길어도 다른 개발자들이 한눈에 이해할 수 있는 변수명을 짓는게 좋다.

옛날에 이름이 긴 변수명을 축약형으로 사용하지 않아서 혼이 났던 경험이 있었다.

나는 그게 왜 잘못된건지 전혀 이해하지 못했고 동료들의 비웃음을 산 적이 있었다.

동료들은 굉장히 경험많은 개발자들이었고 나는 신입개발자였기 때문에 당연하게 '내가 실수했구나..'라고 생각했었는데

지금 생각해보면 어쩌면 내가 신입개발자였기 때문에 고정관념없이 재대로 이름을 붙인게 아닐까?

 

공감하지 못했던 부분

 

인터페이스의 경우 보통 IUser와 같이 대문자 I를 붙여 사용하는 경우가 많은데

이것은 이미 너무나도 널리 알려져 있기 때문에 클린 코드책에 'I를 붙이지 않는 것을 더 선호한다'라는 말 때문에

아~ I를 안붙이는게 좋은거구나 하긴 조금 힘들것같다.