드디어 기다려왔던 리팩토링의 시간이 돌아왔다.
2주라는 짧은 시간안에 목표한 결과물을 내기 위해 불편하고 찝찝한 감정을 덮어두고 달렸다.
프로젝트하면서 리팩토링까지 2주안에 진행할 시간이 없다는 것을 1차 팀프로젝트 때 느꼈다.
그래서 애초에 클린코드를 지향했지만 지금보니 형편없는 코드들이 많다.
도대체 무슨생각으로 이렇게 코드를 짰을까 이해가 안되는 부분들도 보이고
생각보다 깔끔하게 잘 정리해서 한달이 지났지만 코드를 읽고 이해하는데 어려움이 없는 경우도 많았다.
6월 한달 간 인턴 생활을 하며 시니어 개발자분들 코드 열심히 보고 이리저리 따라해본게 이번 리팩토링에서 꽤 도움이 되었다.
그리고 코드 리뷰 받을 때마다 직접 수정하고 새로운 업무에서도 계속 의식적으로 코드 작성을 했더니
조금씩 좋은 습관들이 생기고 있다.
이번 리팩토링의 목표는 불필요한 코드들을 최대한 제거하고 직관적인 코드로 바꾸는 것이다.
인턴을 하면서 받았던 피드백 중 하나가 더 직관적이고 친절하게 변수명을 지어라였다.
나는 나름 변수명 잘지었다고 생각했는데 내 기준보다 훨씬 디테일하게 변수명에 기능에 대한 정보를 담아야했다.
한달 간의 인턴 과정이 끝나고 지난 1,2차 프로젝트 코드 열어보니 이게 뭐하는 애인가 싶은 변수들이 많았다.
이번 리팩토링을 하면서 변수명과 관련된 컨벤션과 직관적으로 코드 정리하는 방법에 대해 정리해보고자한다.
어디까지나 내가 알고있는 것과 새롭게 배운것들을 중심으로 정리하기때문에 아직 부족한 부분들이 많을 수 있다.
하지만 계속해서 보완해나갈 생각이다.
1. 불필요한 콘솔 로그 삭제
우선 가장 기본적인 실수. 그래서 절대 하면 안되는 실수 = 콘솔 로그 남기기
이거 부트캠프 당시 멘토님한테 정말 많이 잔소리 들었다.
데이터 확인하려고 잠시 작성해두고 다른 작업 오류 수정한다고 까먹고 그대로 PR을 올려버린 경우가 있었다.
그후 console 검색해서 모조리 지우고 PR을 올리는 것을 습관으로 만들었다.
(배경화면에 스티키메모로 "콘솔 지우고 올리기"를 써둘 정도)
콘솔 로그 ,, 마치 잡초처럼 어디선가 자꾸 나온다. 이건 내가 작성한 코드는 아니지만 그래도 불필요한 코드 참을 수 없다.
바로 삭제!
2. 사용하지 않는 import 삭제
이것도 내가 짠 코드는 아니지만 불필요한 코드는 줄일수록 좋으니 솔선수범해서 삭제한다.
async 어디에도 사용하질 않는데 굳이 import할 필요가 없다.
3. 변수명 CamelCase 컨벤션 지키기
이건 정말 사소한 부분이라 굳이 수정하지 않아도 되긴하지만 그래도 컨벤션이니까 수정했다.
CamelCase로 작성하는 것이 컨벤션이었는데 All"f"iiled F가 소문자였다.
이런 경우 그냥 코드를 볼때는 문제가 안되지만 혹시 다른 개발자가 CamelCase가 컨벤션이니
당연히 F가 대문자라고 생각하고 AllFilled라고 코드를 작성하면 문제가 발생할 수도 있다.
아주 작은 부분이라 그냥 넘어가기 쉽지만 이런 부분에서 에러가 나면 그래서 더 찾기가 어렵다.
4. 직관적인 변수명
분할 결제시 금액을 반액으로 계산하는 로직에 반액으로 결제되는 금액의 변수명을 PRICEN이라고 지어놨다.
아직도 저 변수명을 쓰던 순간이 정확하게 기억난다.
프로젝트 최종 시연을 앞두고 데이터가 꼬여서 에러가 불꽃놀이처럼 팡팡 터지고 있었다.
거의 전쟁터를 방풀케하는 상황에서 급하게 에러가 난 데이터값을 새롭게 할당하는 과정에서 변수명을 지을 여유가 없었다.
그래서 저런 말도 안되는 변수명으로 지어놓고 나중에 고쳐야지 했다.
그리고 한달이 지나버렸습니다... 반성합니다...
매칭이 이루어질 경우에 반액으로 결제하는 시스템이라 MATCED_PRICE로 변수명을 변경해주었다.
5. 매직 넘버 피하기
코트장 예약을 진행 할때 매칭을 희망할 경우 서버에 matching 으로 숫자 1을 넘겨준다.
그리고 그 데이터를 바탕으로 결제 단계에서 금액을 계산한다.
그래서 매칭 데이터가 1이면 실행되도록 코드를 작성했었다.
나는 통상적으로 1은 true, 0은 false라고 쓰니까 이해하는데 문제가 없을 거라고 생각했다.
하지만
인턴을 하면서 처음으로 알게된 매직 넘버.
태그 기능에서 위와 같이 매직넘버로 코드를 작성했더니 "매직 넘버"를 피해달라는 피드백을 받았다.
공용 태그는 tag number가 1이고 프라이빗 태그는 tag number가 2이여서
태그 타입에 따라 1일 경우는 공용 태그 불러오기, 2는 프라이빗 불러오기를 했었다.
그때 사수분께서 매직넘버에 대한 글을 공유해주시면서 클린 코드를 지향하기 위해 매직넘버를 피하는게 좋다는 얘기를 해주셨고
나도 관련 자료를 찾아보며 그 중요성을 알게 되었다.
의미 있는 이름의 상수로 대체될 수 있는 숫자이다.
위에 내가 썼던 코드로 설명하자면 1일 때 a라는 동작을하고 0일 때는 b라는 동작을 하도록 코드를 작성했다면
그 코드를 읽는 다른 사람들은 이 1는 무엇이며 2는 무엇인지 찾기위해 많은 시간을 소요해야 한다.
어디서 튀어나온 숫자인지 찾아야 한다는 것이다.
그리고 이런 매직 넘버가 많아질수록 코드 가독성이 현저히 떨어진다.
이런 매직넘버를 명확한 상수명으로 변경하면 그 중요성을 느낄 수 있다.
isMatced === 1 { do something }
isMatced === matchedSuccess { do something }
위의 두 줄만 보아도 어느 쪽이 더 명확하고 직관적인 코드인지 알 수 있다.
이렇게 간단한 코드이지만 명확하지 않은 코드로 작성되어 있던 부분을 변경해주었다.
코드가 조금 더 길어졌지만 훨씬 가독성을 좋아졌다.
그리고 이렇게 하면 추후 유지보수를 할 때 코드에 대해 모르는 사람도 쉽게 이해할 수 있다.
7. 함수명 명확하게 짓기
기존의 함수명은 handleChange였다.
체인지를 핸들링하는 함수라는데 너무 불친절하다.
물론 컴포넌트 단위가 작고 코드가 짧을 경우 바로 파악이 가능하다.
그래 아마도 onChange 이벤트 핸들러와 연관된 함수겠지?
하지만 프로젝트가 규모가 커지고 코드가 길어지면? 혹은 비슷한 동작을 하는 비슷한 함수가 많아지면?
그때부터는 강물을 거슬러 오르는 연어처럼 코드를 거슬러 올라가야한다.
위의 코드에서 handleChange 함수는 결제 방법을 선택할 경우 그 데이터를 저장하기 위한 함수이다.
그래서 더 명확하게 기능에 대한 정보를 담아 handleChangePaymentMethod라고 변경해주었다.
이렇게 하면 결제 방법이 변경되는 것과 관련된 핸들러라는 것을 알 수 있다.
변수명이 너무 길어지는 것이 오히려 가독성을 해치지 않을까 걱정을 했었다.
그래서 코드 리뷰 시간에 직접 시니어 개발자분들께 여쭤봤다.
20글자 이상 길어지면 문제겠지만 그 이하로는 오히려 조금 길어도 명확하게 표현하는게
가독성과 유지 보수 측면에서 더 좋다고 하셨다.
리팩토링 하면서...
2차 팀프로젝트라 1차보다 기본적인 컨벤션들은 어느정도 지켜지고 있었지만 디테일한 부분들에 있어 부족함이 있었다.
클린 코드를 늘 가슴에 세기고 코드를 작성하지만 다음날에 다시 보면 형평없는 경우가 있다.
작은 부분들부터 습관으로 만드는게 중요하다는 생각을 한다.
인턴으로 있을 때 프론트엔드 팀장님이 자신은 리팩토링 종류 중 쓰레기줍기를 평소에 항상 실천하려고 한다고 하셨다.
나중에 리팩토링 해야지해도 그렇게 잘 안되니 코드를 짤 때 수시로 쓰레기같은 코드를 치워버려야한다는 것.
빠르게 개발을 진행하는 과정에서 리팩토링하는 시간을 따로 가지기란 쉽지 않다.
그래서 이런 좋은 습관들을 몸에 익혀서 따로 리팩토링 시간을 들이지 않아도 기본적으로 클린코드가 될 수 있도록 노력하고있다.
클린 코드와 소프트웨어 장인 정신
필자가 중요하게 생각하는 것 중에 하나가 바로 장인 정신이다. 장인 정신의 사전적 의미를 우선 살펴보자.
medium.com