[1.1~1.2] 요구사항 분석
"어디다 쓰시게요?"
클라이언트 개발자와의 대화 절반은 저 문장으로 해결 가능하다.
개발을 하다보면 API 명세서를 통해 대화를 하지 어떤식으로 구현하고 어떻게 할건지에 대해 말하는 일을 드물다.
명세서 이외에 API 를 더 만들어 달라고 요청이 들어오면 처음에는 "쓸일이 있으니 만들어달라하겠지~" 라는 마인드가 강했는데, 서버 성능 최적화를 진행하고 로그들을 관리하다보니 API 하나하나 모두 통제하게 된다. (천사표 서버 개발자)
그럴때마다 어디에 쓸꺼냐고 물어보며 대화하면 더 좋은 방법들이 나온다.
클라 개발자는 서버가 어떻게 구성되었는지 모르기 때문에 어디서 부하가 심하고 어떤 부분이 간단하게 해결 가능한지 알 수 없다. 그렇기 때문에 어쩌면 잘 못 됐을 수도 있는 API 변경/추가를 요청하는거고 서버 개발자는 이때 이걸 듣고 더 나은 방법을 쉽고 간단하게 클라 개발자에게 설명 할줄 알아야한다.
그 전에 문제가 안생기게 API 를 설계하고 클라이언트에게 고지하는 것도 중요하다.
얼마전에 채팅 개발을 하다가 채팅방 리스트에서만 유저 정보를 주고, 채팅방 내부에서는 안주는 것을 알았다.
처음 생각할때는 채팅방 리스트에서 받은 유저 정보를 저장 해 뒀다가 쓰라고 안넣어 준것 같은데, 그 유저 정보에 시간에 따라 만료되는 사진 URI 가 있었다. 클라 개발자는 이때문에 나에게 "사진 URI 갱신 API" 를 만들어 달라고 했다. 사실 이 경우는 채팅방 내부 API 설계가 잘 못 된것이기 때문에 기존 API 를 변경했어야 하는 사례이다. 만약 내가 안물어보고 그냥 만들어 줬으면 이런 실수도 잡아내지 못했을 것이다...
[1.3~
