도전 클린코드! API endpoint, routes Path 상수로 바꾸기 (매직넘버, 하드코딩 개선하기)

API EndPoint 리팩토링

현재 하드코딩하여 사용하고 있기 때문에 API가 변경될 일이 있을 경우 하나하나 찾아가야하는 문제가 발생한다.

모든 매직넘버의 문제점이겠지만..

 

이번 하드코딩을 리팩토링하면서 얻을 수 있는 것으로는 아마도 다음과 같을 것이다.

1. 유지보수가 쉬워진다.

2. 상수로 선언하여 코드의 안정성을 높인다.

 

API를 상수로 정의할 때 보편적으로 사용하는 방법이 있는지 모르겠으므로 내 마음대로 고쳐본다.

적어도 사용하는 내가, 그리고 팀원 분이 이해할 수 있도록 작성을 목표로 한다.

 

백엔드 API 문서를 보면서 상수로 정의하고자 한다.

constants 폴더 안에 apiEndpoint.ts 파일을 생성했다.

 

변경 전(하드코딩)

 

우선 변경 전에 axios를 헬퍼함수로 만들어서 사용하고 있는데 endpoint 부분을 계속 하드코딩해서 사용하는 부분이

매우매우 거슬렸지만 기능 구현에 시달리느라 초반에 잡지 못하고 있었다. 🤣

지금도 해야할 구현 목록이 있긴 하지만 더 거슬리기 전에 한번 수정을 해야겠다.

 

 

이런식으로 주석도 예쁘게 달아봤다.

내가 보기 편해야 다른 사람도 보기 편할것 🤗

endpoint 에서도 중복되는 부분은 앞에서 const로 빼주고 템플릿 리터럴을 사용했다.

 

문제는 변수 이름을 짓기가 굉장히 어렵다. 깔깔깔..

함수나 bool 타입을 다루는 상수가 아닌데 변수 네이밍을 동사로 시작하도록 지어도 될까?도 잠시 고민했었는데

어퍼케이스로 작성했으니 괜찮을 것 같다고 판단했다.

누가 선례를 보여주면 참 좋겠다. ㅋㅋㅋㅋㅠㅠ (코린쨩 선배 급구@@@)

 

아무튼, 행위를 먼저 보여주고 싶은 마음에 PET_UPDATE보다는 UPDATE_PET이 조금 더 나은 것 같아서 그렇게 썼다.

만약 별로라면 나중에 다시 고치러 오겠지. (미래의 내가)

 

음, 이것은 어떻게 고칠까 🙄

해당 api는 questionId가 동적으로 변경된다.

따라서 상수로 선언할 수 없다.

그렇다면 답은 함수 밖에 없겠네요..

 

하지만 다른 api는 상수로 사용하고 있어서 해당 api를 함수로 호출해야된다는 것을 당연히 알아채줄까?..

그랬으면 좋겠지만 ㅋㅋㅋ 혹시? 하는 마음에 일단 주석을 달고 본다.

 

사용중인 axios helper 함수 (GET)

현재 사용하고 있는 axios 헬퍼 함수는 endpoint 외에도 param라는 인자를 받고 있어서

사용 시 params 부분을 다음과 같이 사용하는데서 발생하는 문제가 있다.

위 코드는 params에 postId라는 값을 넣고 있는데,

'params에 슬래시를 붙여야하나? 말아야 하나?'에 대해 고민해야 한다는 것부터 어딘가 잘못됨을 알 수 있다.

어차피 axios 헬퍼 함수의 중복 코드도 제거해야 해서 리팩토링을 생각 중이긴했는데

먼저 endpoint부터 해결하고 차근차근 진행해야겠다.

 

params가 동적으로 변경되어야 하므로

엔드포인트 상수 정의 파일에서 함수 호출을 통해 endpoint 하나만 넘기는 방법으로 수정해야겠다고 생각했다.

params를 필요로 하는 부분은 requestQuestionsId 라는 이름으로 함수로 만들었다.

get, put, delete가 동일한 방식으로 사용될 것이라 위에 주석도 한줄 추가해주었다.

 

🎀 1차 완성

현재 백엔드에서 제공되는 API 상수로 정의하는 것은 끝났다.

다 작성하고 일부 상수명은 변경하고 또 어떤 부분이 문제가 있을까?! 고민해봤다.

생각해보니 파일이 하나라서 import해서 사용할 때 이 파일로 어쨌든 다시 와서 (물론 주석을 잘 달아놔서 오더라도 필요한 부분을 찾는데까지는 그리 오래 걸리지 않겠지만)

최악의 경우 상수를 하나씩 추적해야 될 수도 있겠다는 문제점이 있을 것 같았다.

그렇다면 조금 더 그룹화를 해볼 수 있을 것 같다.

 

🎀 2차 수정에 들어가자. 이번엔 객체를 사용한다.

파일을 여러개로 분할하는 방법도 있겠지만 api 파일을 하나로 묶고

그 안에서 그룹화를 하는 방법이 조금 더 간결하게 사용할 수 있을 것 같다고 (내 마음대로) 생각했다.

일단 객체 api 하나 import 하면 내부에 key 뭐 있는지 자동완성 할 때도 조금 더 쉽게 찾을 수 있을 것으로 예상한다.

 

객체이기 때문에 혹시라도! 내부를 수정하지 못하도록 프리징했다.

 

일단 객체 내부의 key값은 보통 camelCase를 사용하지만

객체 내부 key 값을 UPPER_CASE로 사용한 이유는 메서드와 구분하기 위해서이다.

메서드는 camelCase로 작성할 것이기 때문에 import 해서 사용할 때 조금 덜 헷갈릴 수 있을 것 같기 때문이다.

물론 타입 스크립트를 사용하고 있으므로 인자가 어쩌고 하면서 에러를 띄워주긴 하겠지만.

 

객체 네이밍에 Api를 붙여주는 게 더 좋을 것 같아서 questionsApi와 같은 네이밍으로 변경했다.

 

🎀 완성!

생각보다 오래 걸렸다. 백엔드 분께서 또 새로운 API를 뚫어주시면 추가해야한다. 까르르

이제 api를 하드코딩하는 요청을 모두 수정하러 갈 차례다. 출발출발~ 🚗🚕🚌

 

그러던 중 눈에 띈 라우트경로.

왜 내 눈 앞에 나타나..... 

이 친구도 상수로 빼러 가야겠네요......

라우트는 나중에 다시 수정해야 될 수도 있을 것 같아서 일단은 간단하게만 바꿨는데

말이 간단이지 하드코딩 값이 많아서 바꾸느라 엄청 오래 걸려버렸다..

 

라우트 path 상수 일부

나중에 다시 수정하러 올 수도 있겠지만 일단 끝.. (🐶힘듦.)

 

그리고 백엔드에서 추가된 API가 또 있길래(..!!!!!) 다시 추가하러 갔다가 아까 하드코딩 변경하면서 endPoint 상수 사용하는 게 좀 헷갈려서 주석을 조금 더 추가했다.

내가 쓸거면 모르겠지만 팀원분이랑 같이 써야해서 아주 정성스럽게 주석 달아놓기.. 완료..!

한 것도 없는데 왜인지 날이 밝아버린 오늘이었다.ㅋㅋ

 

이제 할 일

메인 브랜치 충돌 해결 하기.. 

충돌 개많이 나서 고생중 ^ㅇ^/

메인 브랜치에 팀원분이 바꾼 폴더명이나 추가된 경로가 있어서 이것도 꽤 오래 걸리겠다..하하