Day 25

📋 팀 회고

원호
- production 환경은 구축했지만, 테스트 코드 리팩토링, 예외 추가할 시간은 부족했다
- API 연동시 안맞는 문제
다함
- 멀티파트가 아직도 어려움... 구현 난이도 최상
- 목데이터여서 금방금방 연결할 줄 알았지만 생각보다 많은 버그및 오타 수정과정들을 거쳤음
- 부상이슈
- 학교 시험 1주일 앞당겨짐(?)
정용
- Posts API 테스트 코드 작성 및 리팩토링
- Common Service 테스트 코드 작성 및 래팩토링
승현
- API 연동도 못했을 뿐더러 테스트했다고 판단한 곳에서 오류가 발생
- 이해가 가지 않는 Event Twice..
- 미비된 UI를 전부 구상하지도 못했음
종표
- production 환경은 구축했지만, 테스트 코드 리팩토링, 예외 추가할 시간은 부족했다
- API 연동시 안맞는 문제

원호
- 서로 같은 곳을 바라보며 만든줄 알았지만 다른 곳을 보고있었고, 기술적인 도전도 어려웠다.
다함
- 만만해보이는 화면 몇개 없는 앱도 정말 많은 기술적 고민이 들어간 것 같음
- 쉬울 것 같다고 지레짐작(?) -> 이게 제일 문제...
- Swagger 더욱 꼼꼼히 보고 이야기 나누기
정용
- 역시 현실은 계획대로 안됨
- 금방 할 줄 알았는데 테스트 코드를 작성하면서 고쳐야하는 부분이 생겨나고, 심지어 로직을 변경하는 부분도 발생했다.
- 이래서 TDD 방식을 사용하는 구나 생각했고, 만약 테스트 코드를 먼저 작성했다면 코드를 고치는 일이 현저히 줄어 들었을 것이다.
승현
- 생각외로 복잡해진 파일과 폴더간의 관계
- 코드의 구성을 파악하기 어려웠고 파일을 찾는데 시간을 많이 소요함
종표
- 계획을 세우면서 새로운 기술이나 개념에 대해 적용을 하게되면 해당 기술이나 개념을 우선적으로 찾아보고 시간이 대충 어느정도 걸릴지를 계산하지 않아서 이런 결과가 발생한 것 같다. 또한, Trinet 라이브러리 내부 코드에 대한 완벽한 숙지가 되지 않았기 때문에 이를 커스텀하기가 어려웠고 이로 인해 거의 하루를 통채로 날려버린셈이다.

원호
- 일단, 가장 중요한 건 기한내에 만들어 내야한다는 것, 만약 제품 출시라면, 못해도 데모까지는 해야된다.
- 잠을 포기하고, 테스트 코드를 포기한다.
- 하지만 실제 API 수퍼테스트는 더 많이 한다.
정용
- 테스트 코드를 작성하지 않는 것을 지양해야 한다.
- 테스트 코드를 작성하면서 자연스럽게 리팩토링도 되고, 잘못된 부분을 캐치할 수 있고, 제일 중요한 테스트 자동화가 가능하다는 것
다함
- 앱이 너무 뜨거워짐...
- 현재 있는 기능 추가 말고, 과거 만들었던 기능에 대해서 버그픽스및 성능 개선을 해야할 듯
승현
- 백엔드와 적극적인 소통이 필요
종표
- 지속해야할 점은 스스로 좀 더 많은 양의 계획을 세우는것이다. 스스로 많은 양의 계획을 세우는 것은 내 발등에 불을 떨어뜨려서 좀 더 노력하고 책상에 앉아있는 시간이 늘어나고 딴짓하는 시간이 줄어드는 것 같다. 하지만, 스스로 많은 양의 계획을 세우게 됨으로써 너무 급하게 기능을 구현하거나 학습을 소홀히 하는등의 부작용으로 인해 오히려 실수하는 부분이 잦았고 그 부분을 고치는데 시간이 추가적으로 더 들어간다는 점을 깨달았다.