참고 블로그 꼭 읽어보자!
API 문서는 프론트와 백엔드(혹은 그 이상으로 일정부분에서는 기획자나 Database)사이의 개발의 기준점이라고 할 수 있는 문서이다.
짧은 team project를 하면서 느낀점이라면, 이런 기준점 없이는 개발의 시작이 제대로 되었을리가 없다라는 것이다.
서로가 서로의 시작점도 끝나는 점도 모르고 만들고 있는데, 어찌 잘 만나겠는가...
특히나, API 문서화 없이 또는 명확한 End point나 In/Out 되는 Data의 설계 없이 개발을 진행하다가는 백엔드 엔지니어 스스로 피를 보는 상황이 나올 수 있다.
이번 Mother Terarosa Project를 진행하면서 다른 누구보다 내가 제일 많이 느꼈을 부분이다...
프론트 개발의 속도가 상당히 빨라 개발을 어느정도 끝낸 상태에서 백의 완성을 기다리고 있었고, End Point나 Data sample 등을 요구하는 상황에서 백엔드 쪽에서는 별다른 소통을 하지 않았다.
프론트 쪽에서는 스스로 형식을 만들어 로직을 만들어 완성했고, 백쪽에서는 뒤늦게 그에 따라가면서 맞추는,, 이상한 형태의 개발이 진행되었다.
늦은 개발 속도를 cover하기 위해 뒤늦게 맡게된 파트에서 특히나 심각했는데, End point의 query parameter가 DB의 설계와 전혀 맞지 않는 방식으로 요청이 들어와 백엔드 로직에서 이를 다 감당해야하는 상황이였다.
코드의 가독성은 박살이 나있었고(로직의 효율성은 말할 것도 없다.) 서버 에러(500)발생에도 디버깅을 할 수 없는 수준이였다.
리펙토링으로 간신히 로직을 단순화하고 함수 분리로 가독성을 높였으나,,, 태생적인 입력값과 DB설계의 미스매칭은 코드에 지저분한 느낌을 남겼다...
대부분의 대기업들 혹은 대기업이 아니더라도 개발을 하는 곳이라면 API 문서를 통해 각자의 API를 설명, 소개하고 있다.
다른 누구도 아니라 내가 해야할 일이고, 책임감을 갖고 내 것으로 만들어야할 작업이다.