[우테코] Lv.3 - 3 ~ 4주차 회고

Sally·2022년 7월 29일
1
post-thumbnail

우당탕탕⚡️ 3, 4주차

3주차, 4주차 나누어서 포스팅을 했어야 했는데 바쁘고 늦어서 이번에는 3,4주차를 합쳐서 회고 포스팅을 하게 되었다 🥲

포코가 레벨 1때 부터 갈수록 바빠진다고 하였는데,
이게 그건가 싶었다.
스프린트 1이 끝나고 1주차 때에는 개발할 시간이 많이 없어서
스프린트 2때에는 팀 전체가 우리의 서비스에 필수적인 기능들을 만들기로 했다.

그러다보니
...

이번 2차 스프린트의 목표를 다음과 같이 잡게 되었다.

  • 카테고리별 게시글 전체 조회
  • 카테고리별 게시글 최신순, 조회순 sort 조회
  • 카테고리별 게시글 무한 스크롤 구현
  • 게시글 수정하기
  • 게시글 삭제하기
  • 댓글 작성하기
  • 댓글 수정하기
  • 댓글 삭제하기
  • 검색하기

꽤나 많은 목표를 잡다보니,
3주차의 월, 화 는 통으로 API 명세를 잡는 것에 할애하게 되었다.
전 단계에서 사실상 로그인 화면과 글쓰기 화면 밖에 그리지 못하다 보니
늘어난 요구사항을 다 보여줄 UI 디자인을 해야할 것들도 늘어나게 되었다.

무엇보다 항상 계획은 나의 생각대로 빠릿빠릿하게 끝나지 않는다.
3주차 때에는 주말에도 캠퍼스에 나와서 코딩을 했는데도 불구하고
원하는 목표만큼 기능을 구현하지 못했다😱
3주차 평일에 UI는 다 그려놓을 수 있을 줄 알았는데, 주말이 되서야 UI를 그려내기 시작하였다.

이렇게 3주차에 하고자 했던 일들이 조금씩 밀려나면서
4주차에 들어서서는 일단 데모데이 전에 돌아가게만 하자 라는 마음가짐으로 리팩토링은 차선으로 치우치고 기능 개발에만 몰두했다.

결과적으로는

  • 카테고리별 게시글 전체 조회
  • 카테고리별 게시글 최신순, 조회순 sort 조회
  • 카테고리별 게시글 무한 스크롤 구현
  • 게시글 수정하기
  • 게시글 삭제하기
  • 댓글 작성하기
  • 댓글 수정하기
  • 댓글 삭제하기
  • 검색하기

목표했던 것들을 다 성공해내지는 못한 채 위에 체크된 부분들만 기능을 구현할 수 있었다.

API 🩹 수정에 수정을 더해서

우리팀의 경우, API 명세를 정할 때에 프론트와 백엔드 모두 참여하여
함께 각각의 기능에 대한 세부 기능과 유저 흐름등을 상의해나간다.
그러다 보니 API 명세를 정하는데 시간이 조금 걸리는 편이다.

이번 3주차의 경우,
월요일은 이번 2차 스프린트 목표와 기능들을 상세히 잡아가고,
화요일에는 해당 기능들에 대한 api 명세서를 작성했다.

통으로 2일 정도를 API 명세에 할애했다.


*사투의 흔적들...

정말 충분한 상의를 했기 때문에 API를 수정할 것이 없을 것이라고 지레 짐작했었다.
그런데 프론트와 백엔드 서로 기능 구현을 진행하면서 이 API는 수정해야할 것 같은데? 라는 점들이 3가지 정도 나왔다.

예를 들어 게시글 상세 조회를 할 때에 불필요한 카테고리에 대한 내용을 url에 첨부하거나
게시글 조회시 각각의 게시글에 대한 id 가 필요했었는데 오지 않는
필요한 값이 응답값으로 안 오는 부분들이 발견되었다.

해당 현상에 대한 우리 조 나름의 원인을 파악해보자면,
2가지 정도를 뽑아 볼 수 있을 것 같다.

첫 번째로, 쉬는 시간을 거의 가지지 못하고 장시간 회의를 했다.

우리조의 경우 1시간 회의를 한 경우 10분을 휴식하는 것을 규칙으로 삼고 있었는데,
이번 API 명세 회의 때에는 할 것도 많거니와, 조금만 더하면 끝날 것 같다는 생각 때문에 해당 규칙을 지키지 못했다.
그러다 보니, 자연스럽게 회의를 참여한 팀원들의 집중력도 떨어지고 체력적으로도 힘들었을 것 같다.
앞으로는, 쉬는 시간을 가지는 것이 수정하는 시간을 줄일 수 있는 방법이 될 수 있을 것 같다.

두 번째로는, 한 번에 API 명세를 많이 한 것이다.

이번 스프린트에서 목표로 삼은 기능들에 대한 명세를 하루에 다 정하고 갈려다 보니, 회의가 자연스럽게 길어지게 된다. 그리고 그 때에는 그 상황에 맞게 api 명세를 잘 짰지만 개발을 하면서 명세가 달라지기도 했다.
2주의 짧은 기간이라고 해도, 그 사이에 기능을 개발하면서 요구사항이 수정 또는 삭제되거나 구현과정에서의 꼭 받아야 하는 값들이 추가 되곤 했다.

♻️ 리팩토링이 필요해

앞서 말한 대로, 제한된 시간에 기능 개발을 다 해야하는데 시간이 부족하다보니 일단 돌아가게만 하자 라는 목표로 코딩을 막?했다.
1차 스프린트 때에 코딩을 한 것들도 제대로 리팩토링이 이루어지지 않은 상태이라 1차 때 부터 적재 된 리팩토링 해야할 것들이 너무 많다.

지금 일단 리팩토링을 하고 싶은 부분들은 아래와 같다.

  • 로딩 중 화면
  • 에러 처리
  • Not found 페이지
  • 리액트 쿼리 커스텀 훅으로 빼기
  • 컴포넌트 분리, 통일성 있게 하기
  • Url 주소 .env로 옮기기
  • dev dependencies 정리
  • Webpack build 문제 해결하기
  • 프론트엔드 자동배포
  • 반응형 화면 구현하기
  • aria-label챙기기
  • favicon
  • 에러 바운더리
  • alert -> snackbar로 처리 하기
  • 작성한 시간을 몇분 전 이런식으로 표기해주기

현재, 비동기 통신에서의 에러 상태와 로딩 상태 일때에 단순히
로딩중 그리고 에러가 발생하였습니다라는 문구만을 표시하고 있다.

제일 눈에 잘 띄는 콘텐츠 부분에 보여지는 것이기에 유저의 사용 경험을 매우 떨어뜨린다. 그래서 우선적으로 해당 부분을 처리해줘야 할 것 같다.

그리고 현재 컴포넌트 구현 부에서 비동기 통신 로직과 render하는 부분이 혼재되어 있기에 코드를 깔끔하게 관리하고 추후에 비동기 통신을 하는 곳에 변동이 있더라도 처리하기 쉽도록 리액트 쿼리를 구현한 비동기 통신을 모두 커스텀 훅으로 처리할 예정이다.

컴포넌트들의 경우도 한 컴포넌트에서 여러가지 하는 일들을 자식 컴포넌트 - 부모 컴포넌트 관계로 나누어서 한 컴포넌트에서는 되도록 한가지 일만 처리하도록 처리하고 싶다. 그런데 컴포넌트를 어떻게 나눌 것인지에 대해서 자세히 생각해보지 못하여서 방법을 좀 더 찾아 강구해야할 것 같다🤔

0개의 댓글