개선 전 상황
처음 프로젝트 시작 시 팀원들과 파일과 변수명에 대한 논의를 거치지 않은 채 작업을 시작하였다. 따라서 파일이나 변수명을 보아도 어떤 역할을 하는지 파악하기 힘들었다. 특히 api 파일과 함수명이 문제가 많았다. api 호출 함수이지만 어떤 api를 호출하는지 파악하는 것이 어려웠다. 따라서 일정한 규칙을 만들어 모두 통일하게 되었다.
개선 방향
-
이벤트 리스너 관련 함수명 통일
이벤트를 다루는 핸들러 함수명이 매우 다양했다. 하지만 어떤 대상에 대해 어느 이벤트를 다루는지 함수명을 통해 파악 가능해야 한다고 생각했다. 함수의 목적과 대상을 알아야 유지보수가 수월하기 때문이다. 문제가 발생하는 함수 찾는것도 함수명이 기능과 대상을 잘 표현하지 못한다면 꽤 비용이 많이 드는 일인 것 같다. 따라서 이벤트 함수명을 {대상}{동작}Handler로 통일하였다. 예를들어 종료 아이콘 클릭 처리 함수의 경우 closeIconClickHandler로 함수명을 통일하였다. -
api 관련 함수 및 파일
api 호출 함수명의 가장 큰 문제점은 어느 api를 호출하는지 파악하기가 힘들다는 것이었다. 그래서 어느 method로 어느 resource를 호출하는지 함수명에 기입하였다. 하지만 문제는 기준을 어디에 두냐는 것이었다. 백엔드 url 기준으로 할지 프런트에서 생각하는 resource 기준으로 할지 고민이었다. 나는 고민끝에 백엔드 url기준으로 함수명을 지정하였다. 그 이유는 api 관련해서 백엔드 엔지니어들과 소통해야 하는 일이 많아서 함수명 통일이 소통에 조금이나마 도움이 될 것 같았기 때문이다. 실제로 어느 api가 문제인지 문의가 들어올 때 함수만 보고도 대답을 할 수 있는? 약간의 도움이 되었다. 하지만 이것도 문제가 있었다. 백엔드 엔지니어가 method나 resource를 잘못 설정하면 문제가 되었다. get동작을 하는 api인데 post를 사용하는 경우가 있었다. 이 경우 어떤 기준을 따라야 할지 고민이 되었다. 나는 그래도 백엔드의 기준을 따르기로 했다. 기준이 많아지면 복잡해지고 다른 사람이 봤을때 파악이 힘들다 생각했기 때문이다.
느낀점
위 두가지 경우 이외에도 통일한 변수명이 많았다. 하지만 나 혼자서 많은 파일들과 변수명을 모두 수정하는 것은 쉽지 않았다. 처음부터 모두 정하고 시작할 수는 없지만 팀원 모두 명명법의 중요성을 인지하고 계속 맞춰 나가는 것이 중요한 것 같다. 하지만 지금은 각자 프로젝트를 혼자서 맡아 진행하다보니 쉽지 않은 것 같다.
