주석에 대한 고찰과 주석 덕지 코드 리팩토링 🌼

Yunny.Log ·2023년 6월 22일

나의 외주일지

목록 보기

15/16

나는 코드를 작성할 때 주석을 참 많이 쓰는 타입이다.
의도는 내 코드에 대한 의미를 명확히 하고자 덧붙이던 의도였으나, 이러한 의도가 좁은 측면에서만 생각한 결과가 장기적으로 봤을 시 더 좋지 않은 결과를 야기할 수도 있음을, 정말 감사한 개발자 시니어님의 높은 고견을 들을 수 있던 기회를 통해 깨달을 수 있었다. 😊
이러한 피드백을 듣고, 문제점에 대해 생각해보고 내 코드의 덕지덕지 주석 코드를 리팩토링 해나가보기로 결심했다!

주석이 코드에서 분리어 점점 더 부정확한 고아로 변하는 사례가 너무도 흔하다.

코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 애초에 주석이 필요 없는 방향으로 에너지를 쏟는 편이 좋다.

부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다.

예를 들어 직원에게 복지 혜택을 받을 자격기 있는지 검사를 작성하는 코드를 작성할 때 아래와 같은 주석 덕지 코드 vs 코드 그 자체로 로직을 표현한 코드를 비교해보기만 해도, 후자의 코드가 보다 로직적으로 깔끔하고, 주석이 필요가 없어져 코드가 간결해짐을 볼 수가 있다.

// 직원에게 복지 혜택을 받을 자격기 있는지 검사
if ((employee.flags & HOURLY_FLAG) &&
    (Employee.age > 65))

if (employee.isEligibleForFullBenefits())

<내 기존 코드>

의미적인 측면 : -1이 의미하는 바가 무엇인지 명확하게 알 수가 없다
메모리 측면 : 컴파일 시점에 -1을 컴파일 할 때마다 스택 영역에 할당할 것이다 -> -1이 여러군데 쓰이면 그때마다 메모리에 생성될 것이다,

위와 같이 -1에 의미를 부여해줄 수 있도록 명명하는 과정을 거쳤다.
디폴트 라우트 아이디라는 상수를 설정해, 단순히 -1L 로 표현하는 것이 아니라 상수에 의미를 부여해, 그 자체로 이 코드의 의미가 무엇인지 파악 가능하다.
개선 1 : 메모리에 한번만 할당
개선 2 : 무의미한 상수가 아닌, 변수명으로 의미 식별 가능 & 주석 제거해도 가독성 up

<코드의 의도> :
각 모듈에 해당하는 넘버가 들어오면
그 모듈은 거부가 된 것이므로 임시저장을 활성화, 읽기 모드 비활성화하는 과정을 수행하고 싶다.

1. 의미 없는 숫자와 주석 (빨강 부분)

숫자로 각 모듈들을 식별하려고 했다.
각 숫자가 어떤 모듈을 의미하는지 주석으로 표시하려고 했는데, 오히려 이 주석때문에 혼란이 가중된다, 보면 프로젝트는 3이 프로젝트라고 코드에 적혀있는데, 주석엔 9가 프로젝트라고 적혀있다 .. 최악의 주석이다.

2. 각 코드가 무슨 역할을 하는지 식별 어려움 (노랑 부분)

개선 1. 의미 없는 숫자와 주석 => 상수화 하고 이름을 붙여주며 상수 그 자체로 의미 식별 가능

개선 2. 코드 역할 의미 식별 가능

위 내 기존 코드들을 살피다보니 정말 부끄럽고, 과거의 나와 싸우고 싶다는 생각이 들 정도로 코드의 가독성이 떨어졌다. ㅠㅠ
코드 주석의 위험성과 비효율성을 파악하고, 유지 보수 중인 프로젝트의 코드를 조금씩 리팩토링 중이다! : 코드 리팩토링을 진행중인 Github 이슈
장기적으로 가독성 있고, 코드를 간결하게 유지하기 위해서는 초반에 메소드, 변수에 대한 철처한 컨벤션 설정에 대한 중요성이 높다.
나는 처음에 이에 대한 점을 깨닫지 못하고 프로젝트 초반에 변수명 컨벤션, 메소드 컨벤션 에 대해 설정해야할 중요성에 대해 알게 되었다.
내 코드에 책임을 가지고, 다른 이들이 코드만 보고도 의미를 식별할 수 있도록 하자, 내 코드를 이쁘게 가꾸자 🌼