내 코드 퀄리티를 올리는 개인적인 관점

연차가 찰 수록 회사에서 내가 작성했던 코드들의 수가 많아졌다.

 

그렇다 보니

그 코드를 인수인계받은 다른 팀원이 "이게 어떻게 동작하는 건가요?" 혹은 "이렇게 짠 이유가 뭔가요?"라는 질문을 가끔 듣는다.

 

그런데 실상 코드를 작성한 지 한 달만 지나도

내가 작성했던 코드의 의도를 까먹는 경우가 굉장히 많다.

 

이런 경우가 반복되다 보니 코드를 작성하면서 나만의 검증방법이 생겼다.

 

이 방법은 다수가 좋다고 해서 검증된 것이 아닌 그저 내가 코드를 작성할 때 나의 코드 퀄리티를 측정하는 방법입니다. (뇌피셜 주의...)

그냥 평범한 한 3년 차 개발자는 이런 생각하면서 코드 짜는구나... 하고 봐주시면 감사하겠습니다.

 

---

리팩토링은 코드를 작성하면서 한다

신입 때는 사실 코드를 다 작성하고 테스트 - 빌드 - 배포를 거치고 그 코드를 개선하는 게 리팩토링이라고 생각했다.

 

그러나 서버에 배포까지 된 나의 애플리케이션은 "아 그래도 동작하네."라는 안일한 생각으로 업무에 치이거나

"해봤자 TPS가 높아지는 것도 아닌데." 이런 생각을 가지다 보면 리팩토링을 안 하게 되고,

시간이 지나 결국 그 코드에 대한 질문은 나에게 되돌아와서

내가 내 예전 코드의 의도를 파악하는 시간 + 물어본 사람을 설득시키는 시간 + a 등등해서 오히려 생산성이 더 떨어진다.

 

그렇기 때문에 코드를 작성할 때, 요구사항의 단계를 나누고 그 단계별로 메서드를 분리해서 

실질적으로 그 요구사항을 실행하는 부분 (Service Layer)에서 그 메서드들을 순서대로 배치한다.

이렇게 하면서도 나눌 것이 있다면 더 나누고 더 쪼갠다.

 

---

주석 사용은 최대한 지양한다.

주석은 코드 실행에 영향을 주지 않는다.

하지만 코드를 보는 개발자의 시야엔 영향을 준다.

 

극단적이긴 하지만 단순한 예시를 들면 A기능을 구현하려고 한다.

공식 문서 보려고 검색을 했는데, 

핵심만 짚은 30라인의 문서1과 내부 원리, 동작과정 등등을 담은 1만 라인 이상의 문서 2가 있을 때,

 

기술적인 공부, 프레임워크(라이브러리)의 의도 파악 등등의 이유를 다 떠나서 어떤 게 더 읽기 좋은 혹은 편한 문서일까?

 

당연히 문서1일 것이다.

 

주석이라는 것을 보는 순간,

이 코드가 테스트를 위해 주석된 건지... 설명을 위해 주석을 한 건지 등 주석의 의도를 파악해야 하는 피곤함도 따른다.

 

내가 작성한 코드는 특정 한 도메인의 서비스를 위한 비즈니스 로직이지 기술이 아니기 때문에 

불필요한 내용으로 코드가 길어지는 건 옳지 않다고 생각하여 주석은 최대한 사용하지 않는다.

 

다만 메서드명, 변수명 등등이 주석을 대체할 수 있도록 가독성 있게 지으려고 노력하는 편이다.

예외 사항이 두 가지 있는데, 특정 IDE에서 지원하는 기능이 있는 주석은 예외이다.

(ex : Intelli J에서 TODO,FIXME 등의 주석을 사용하는 경우)

 

---

타인의 시선으로 바라본다.

코드를 다 작성하고 나서 테스트까지 끝이 났다.

그러면 이제 빌드 및 배포가 남은 상황이라면 나는 내가 짰던 코드를 다 잊어버리기 위해 노력하고 

머릿속을 비운다.

 

그런 다음에 내가 이 코드를 유지보수 해야 하는 입장이라면

어느 부분에서 읽기가 싫어질까?를 판단한다.

 

내가 이런 생각을 많이 했었어서 아마 이런 과정을 거치는 것 같다.

 

머릿속을 비운 후, 내 코드가 어떤 의도고 어떤 순서로 이루어져서 어떤 결과를 도출하는지 파악해 본다.

 

이 과정을 거치면 여기서 이 변수명 혹은 메서드명이 명확하지 않다.

혹은 이 메서드는 단일 관심사가 아닌 여러 관심사를 처리하는 메서드구나 등등 

고쳐야 할 점들이 눈에 보인다.

 

타인의 시선으로 바라보다 보면 내 코드를 수정할 사람의 미래 물음에 대해 미리 코드로서 답할 수 있다.

---

나와 비슷한 일을 하는 게 아닌 다른 개발자에게 코드가 읽기 좋냐고 물어본다.

프로그래밍 언어라는 게 맥락상 큰 차이가 없기 때문에 

개발자라면 아 이건 변수구나 이건 메서드구나 등등의 형태를 알 수 있다.

 

내 코드를 다 작성하면

나와 같은 백엔드 개발팀에게 물어보는 게 아닌 전혀 다른 일을 하고 있는

프런트엔드 개발자에게 묻거나 앱 개발자에게 전혀 도메인 지식, 흐름 등을 설명하지 않은 채 보여준다.

 

그런 다음 "이 코드가 어떤 의도로 작성된 것 같냐?"라고 물어봤을 때 

내가 작성한 의도와 어느 정도 일치하는지를 파악한다.

 

그렇다면 나는 여기서 이런 의도로 짠 건데 이렇게 해석할 수 있구나를 파악해서 좀 더 의도를 명확하게 하기 위한 조치를 취한다.