[주간 회고] 22.04. 1주차 - "안드로이드 팀과 협업, 의사결정 문서화, Restful API, ATDD"

👾 회고

22.04.04 ~ 04.15(2주) 간 안드로이드 팀과 간단한(?) 협업 프로젝트(Todo App)를 시작했다. 클라이언트 개발자 / 서버 개발자를 나누어 개발을 시작하게 된 것이다. 가장 재밌고 많이 배운 점은 바로 협업이었다. 팀원 모두 같은 목표를 가지기 위해 프로젝트 기획서, 요구사항을 세밀히 분석했다. 그라운드 룰을 정하여 업무의 통일성(스크럼, 브랜치 전략, 커밋 컨밴션, 프로젝트 관리(Github의 Projects 사용, Issues, PR 관리 등)를 두었고 백엔드 기술적으로 Rest API와 DB 설계를 해보았고 제공할 수 있는 한 주였다. 무지성으로 기술을 선택하지 않으려 했고 왜 이런 의사결정('기술 선택')을 했는지 문서화하려 했다. 또한 배운것을 나눌 수 있었다.(아예 다른 백엔드 팀들에게)

 

📚 배운 것

월요일 (04.04)

첫 만남의 날 잡담을 통해 아이브 브레이킹, 팀-프로젝트 협업을 위한 약속, 관리 방법 결정했다.

- 팀원 소개, 저장소 생성, 그라운드 룰 결정(Git flow, Issue 관리, 프로젝트 관리) 

 

문서 작성

- 깃허브 저장소에서 이슈 템플릿, PR 템플릿 적용하기 (feat. .github 폴더)

- 팀 그라운드 룰

---

화요일 (04.05)

클라이언트, 서버 개발이 동시에 이뤄져 클라이언트 개발자가 API 없이 개발해야하는 불편을 발견했고, 클라이언트 개발자들을 위해 mockup api server를 빠른 시간 안에 제공하기로 결정했다.

 

한 일

- 요구사항 분석, API, DB 설계, Mockup API Server 제공, PR : API 설계

 

문서 작성

- Mockup API Server 활용과 Postman Mock server 사용 (도입 이유와 기술 비교)

 

---

수요일 (04.06)

본격적인 스프링 서버 개발을 시작했다. 특별한 점으로 ATDD 연습을 했다. 반복되는 테스트를 어디서 끊어내야 할 지 고민이다. (계층별 반복되는 단위 테스트가 반복된다. 요구사항이 바뀐다면 테스트코드도 바뀐다. 리팩토링 내성에 대해 강한 테스트 코드를 어떻게 작성해야 할까?)

 

한 일

- 서버 개발 시작, ATDD로 구현 연습 (API 1개 구현 중)

---

목요일 (04.07)

API 개발을 하고 현재 진행한 곳 까지 AWS 배포를 하였다.

 

한 일 

- 1개 API 구현 완료, PR : API - Todo를 특정 id로 조회 요청

- AWS 배포 완료(프리티어 제약으로 1개의 ec2에 Spring + MySQL(내부 접속만 허용))

---

금요일 (04.08)

현재까지 구현 사항을 되돌아 본 시간이었다. 리뷰어 Dan과의 미팅을 통해 올바른 Restful API란 무엇인지 고민할 수 있었다. 초기 로이 필딩이 제안한 Restful API와 100% 동일한 API가 과연 좋은 API 일까?, 반복되는 테스트 코드는 어디까지 설정해야 하는가?, 실무의 커밋 메세지는? , MVC 패턴에서 도메인 영역과 리포지토리의 연결된 문제점을 되돌아 봤다.

회의가 끝나고 안드로이드 팀원에게 제공한 API에 대해 반성할 수 있었다. API는 백엔드 개발자를 위한 것이 아닌 클라이언트 개발자를 위해 설계되어야 한다는 점을 잊지 말아야겠다. 

 

한 일  

- PR 피드백 점검

- 미니 데모 발표(마스터 아이비의 피드백)

- 리뷰어 Dan과의 미팅

---

토요일 (04.09)

- 휴식

 

일요일 (04.10)

- 주간회고 작성

---

Reference

- 협업 프로젝트(Todo App)

- 프로젝트 위키

- 깃허브 저장소에서 이슈 템플릿, PR 템플릿 적용하기 (feat. .github 폴더)

- Mockup API Server 활용과 Postman Mock server 사용 (도입 이유와 기술 비교)

- 사진 : Annie Spratt - Group of people