[일일 회고] 22.04.19~20 - "Mockup API 서버, 기능 요구사항 분석과 개발 기간 결정, 테스트 코드 전도(?)"

Mockup API 서버

상황

반찬가게 웹 개발 프로젝트를 시작됐다. 기획서만 주어졌다. API, DB 설계할 시간 없이 프론트, 백엔드 개발이 시작됐다.  

 

문제

API, DB 설계안 없이 시작하다 보니 프론트 개발자는 단순 view, 디자인을 그릴 수 있었지만 비즈니스 로직을 구현할 수 없었다. API 서버가 없기 때문이다. 백엔드 입장에서 당장 API 서버를 제공해주고 싶었지만 API, DB 설계할 시간과 서버 구현할 시간도 필요했다.  

 

해결

Mockup API Sever를 도입하기로 했다. Mockup API는 코딩 없이 비교적 간단하게 만들 수 있었기에 프론트엔드와 함께 설계하며 만들 수 있었다. 백엔드 입장에서 프론트엔드가 원하고 필요한 API 피드백을 빠르게 받을 수 있고, 프론트엔드는 실 API 서버 배포 전에도 개발을 할 수 있다는 이점을 가질 수 있다.  

 

기술 선택

postman mockserver, node.js(JSON Server), node.js(express) 기술 중 프론트가 JS를 사용하기에 node도 고려했으나, postman의 손쉬운 사용과 외부 접속 가능, API 문서화 제공해주기에 postman을 선택하게 되었다.

 

결과

Side Dish 웹 애플리케이션 Mockup API Server 문서

 

기능 요구사항 분석과 개발 기간 결정

기획서를 보며 기획/요구사항에 대한 기능 요구사항을 분석했다. 시스템 구성도는 어제 완료하였고 핵심 기능별 동작 흐름과 상세 기능을 테스트 별로 구분하였다. 예를 들어 프로트엔드가 특정 음식 타입 조회를 하게 해 주세요 의 요구사항이 있다면 성공한 경우, 실패한 경우를 분석하여 구현을 나누었다. 작은 테스크로 구분하니 팀원과 일을 분담할 수 있게 되었고 프로젝트 일정을 정할 수 있었다. 재미있던 점은 구현하기에 앞서 팀원 별 예상 구현 시간을 적었다. 팀원과 구현 시간의 차이가 있었는데 둘의 구현의 범위가 달랐다.(나는 테스트 코드까지 포함하여 2배 이상의 시간이 든다고 했다.) 구현을 마치고 실제 구현 시간을 비교하여 왜 차이가 발생했는지도 회고하면 재미있을 거 같아 남겨두었다. (요구사항 분석 문서(notion))

요구사항 분석 문서(notion)

페어 프로그래밍과  테스트 코드 전도(?)

팀원은 Spring MVC에서 테스트 코드를 작성해본 적이 없었다. 테스트 코드 작성에 부담이 있었고 이를 위해 페어 프로그래밍을 하며 테스트 코드를 전도하기로 했다. 페어 프로그래밍을 하면서 위에서 결정한 인수 테스트 하나를 함께 구현하기로 했다. 생각보다 반응이 뜨거웠고 하루뿐이었지만 테스트 코드를 전파했다는 것에 만족하였다. 페어프로그래밍의 목표를 인수 테스트 1개 성공하는 것으로 정하면 재미있을 거 같다.

간단한 인수 테스트