Week4. Day5 ‐ 23.12.01 주간회고

각 절차의 목적

• 스크럼 : 업무의 진척도를 확인하고, 문제가 발생한 업무의 재분배를 위해 수행
• 회고(KPT) : 팀원의 "고민"과 "문제" 상황을 공유 및 해결 방안을 모색하고, 이를 통해 세운 해결 방안의 유효성을 지속적으로 점검하기 위해 수행
• 코드 리뷰 : 버스 팩터의 향상과 팀 코드 품질 향상을 위해 수행
• 상기의 업무의 목적을 기준으로 매주 주간 회고에서 팀 업무의 수행 결과를 점검

데모

• 스프린트 4주차 개선사항 참고

  • https://plastic-toad-cb0.notion.site/1b555ef8828c44869063f71f81cfaaba?v=555ffb27ea4f4657befd50b22ec18a58&pvs=4

• 전반적 개선사항

  • 데이터 요청 후 프론트와 백의 데이터를 일치시키는 방법 논의 필요
    • ex) POST 이후 GET (post 요청에 대한 응답으로 성공/실패여부 전송하고, 성공이면 생성된 id를 반환하여 get 요청을 다시 보내서 생성된 데이터를 받아옴) OR POST (post 요청에 대한 응답으로 변경된 데이터를 보내줌)
  • 프론트에서 전역 상태 관리가 안 되어 있어서 프로젝트 아이디, 유저 이름-아이디매핑 등 상태유지가 안됨
    • ex) 프로젝트 선택 시 선택된 프로젝트의 스프린트/백로그를 볼 수 없음
  • 회원을 식별해서 권한 부여하는 로직

• 지라 태스크

  

문제점

• 시간부족

  • 멘토링이후 팀의 방향에 대해 논의하는 기간이 길었음

• 과도한 목표설정

  • 자잘한 기능이 많아 실제 구현을 해보니 오래걸리는 부분이 많았음

• 의존적인 작업이 많음

  • ex) 프론트 - 백 API연결

• 백 테스트코드가 없어 안전한 코드인지 확신이 없음

• 수린

  • 라이브러리를 정하는데 너무 많은 시간을 들여서 실제로 구현하는 시간을 확보하지 못했다.

• 승민

  • 번다운차트 직접 구현하려고 하는게 오래걸렸다.

• 서정

  • API를 빠르게 작성해야한다는 부담감에 돌아가는 코드를 만드는데 급급함
  • API를 테스트 해봐야하는데 에러가 발생하면 프론트-백 중 어디 문제인지 모호하다.

개선방안

• API를 테스트 해봐야하는데 에러가 발생하면 프론트-백 중 어디 문제인지 모호하다.
  • 백에서 에러처리를 신경쓰자
  • EX) 500에러보다는 다양한 상황에 대해서 에러를 판단할 수 있게 설계하자.
• 과도한 목표설정
  • 없는 기능을 개발하기보다는 현재의 기능을 개선하는게 더 적절함
• 백 테스트코드가 없어 안전한 코드인지 확신이 없음
  • 테스트코드 꼭 개발하기