메가테라 웹 개발자 과정 19주차 주간 회고

 

2주차 스프린트 주간 작업 목표 및 성과 분석

2주차 스프린트 주간에는 지난 주간에 구현하지 못했던 게시글 목록 조회를 마저 구현하고, 상세 내용 조회까지 마치는 것을 목표로 했다. 상세 내용 조회 구현 시에는 다음의 조건을 만족할 수 있도록 했다.

 

• 참가자 관점: 인원이 부족한 포지션에 등록을 신청하거나, 등록된 경우 등록을 취소할 수 있음
  
  • 신청 가능한 포지션에는 신청하기를 누를 수 있음
  • 인원이 마감된 포지션은 신청할 수 없음
  • 자신이 신청한 포지션은 신청취소가 나타나고 다른 포지션에는 신청할 수 없음
    
    
• 작성자 관점: 신청 목록을 확인해 신청자의 신청을 수락하거나 거절 가능
  • 각 포지션마다 신청자 목록을 확인할 수 있음
  • 신청자의 신청을 수락하거나 거절할 수 있음
  • 거절당한 신청자는 거절 리스트에 추가되어 작성자가 반려하기 전까지 포지션에 신청할 수 없음
    
    

 

현재 구현 진행 상황은 참가자 관점에서 등록하지 않은 게시글의 경기에 등록을 신청하거나, 신청한 등록을 취소할 수 있는 내용까지 구현한 상태이다.

 

2주차 스프린트 주간 스토리 포인트 사용량 분석

	예상	실제	미완
모델 구조에 객체 추가	4	2	0
운동 모집 게시판 리팩터링 (프론트엔드)	6	10	0
운동 모집 게시판 리팩터링 (백엔드)	9	19	0
네비게이터 생성	1	1	0
운동 모집 게시글 상세 정보 기본 내용 출력 (프론트엔드)	6	9	0
운동 모집 게시글 상세 정보 기본 내용 출력 (백엔드)	5	6	0
운동 모집 게시글 상세 정보 - 사용자 포지션 신청 여부 기준 포지션 컴포넌트 출력 구분	6	13	0
운동 모집 게시글 상세 정보 - 작성자 신청 수락, 거절 기능 (도합)	20	0	20
합계	57	60	20

 

스토리 포인트 사용량은 다음과 같이 집계되었다. 대부분의 진행한 계획에서 스토리 포인트 사용량이 1.5배에서 2배 가량 불어나면서 진행 정도에 차질이 빚어졌다.

 

이번 주간은 '올바르지 못한 설계를 작은 단계에서 개선하지 않았을 때, 규모가 커질수록 어떤 좋지 않은 영향을 미치는가'를 몸소 느꼈던 한 주였던 것 같다.

 



게시물과 관련된 기능을 위한 모델들과 게시물 기능에 대한 테스트 코드를 다시 한 번 들고 왔다. 이미 해당 로직은 하나의 REST API 요청이 너무 많은 모델을 참조해야 하는 구조였기 때문에 예상했던 스토리 포인트의 두 배 이상인 약 19 스토리 포인트를 사용하고도 최종적으로는 테스트 코드 작성을 포기하고 기능만을 구현한 형태가 되었다.

 

관심사가 너무 많이 몰려 있는 구조의 문제는 해당 구조에 새로운 기능을 추가해야 할 때 다시 한 번 큰 이슈로 나타났다. 동작이 복잡해진 상태가 되었기 때문에 몇 부분의 참조가 추가되는 데에도 오랜 시간 소스코드를 살펴보면서 내용을 추가하고, 추가되면서 나타나는 다른 영역에서 발생하는 오류들을 잡아야 했다.

 

노아님과 스프린트 주간 회고를 하면서 작업에 들어갈 때 모델들 간의 협력 구조를 충분히 고민하지 않고 설계를 진행했음을 체크했다. 그 과정에서 내가 객체 지향 설계를 잘 이해하지 못하고 있음을 느꼈고, 잘못된 설계를 따라 구현을 하고 있을 때 테스트 코드를 짜기 어려움을 느꼈을 때 질문을 해서 문제가 작을 때 바로잡을 수 있었다면 어땠을까 하는 생각이 들었다.

 

 

3주차 스프린트 주간 작업 계획

현재 작업 계획을 수립하지 않았다. 오늘 아샬님의 설계 문서 리팩터링 강의를 바탕으로 사용자 스토리, REST API 설계를 비롯한 설계 문서를 전체적으로 재정비하고, 리팩터링한 사용자 스토리를 바탕으로 작업 Task의 크기를 조정해서, 남은 주간 동안 작업 계획을 세울 때 지금처럼 계속해서 작업이 계속 불어나지 않도록 해야겠다는 생각이 든다.

 

올바른 애플리케이션 개발 과정에는 작업 설계가 구현보다도 많은 시간을 들여야 한다고 한다. 이제는 Github Projects의 Task 테이블에 작성하는 그때그때 구현 전에 작성하는 작업 설계 방식이 아니라, 내일 전체적으로 구조 설계를 다시 생각하면서 문서에 작성해야 하겠다.

 

그리고 올바른 객체 지향 설계를 위해 미뤄두고 있던 객체지향의 사실과 오해를 읽는 것을 마무리하는데, 도메인 모델 구조도가 어떻게 구성되어 있는지 집중적으로 살펴보고 마카오뱅크 풀스택 강의의 모델들 간 협력 관계에 빗대보면서 개별적인 모델들이 어떻게 협력하는지 정리해야 하겠다.

 

화요일 저녁과 수요일 점심 사이까지 '1차적'으로 개선한 설계 문서과 작업 리스트를 바탕으로 이번 주차 스프린트 티켓을 노아님과 상의해서 발행하는 것을 일단 목표로 삼으려 한다. '1차적'이 중요한 포인트이다. 사용자 스토리를 비롯한 문서의 내용은 한 번에 설계하기 어려운 내용일 수 있다. 최대한으로 고민하되, 해법이 도저히 떠오르지 않는 영역은 일단 빈 칸으로 남겨두고, 주기적으로 설계 문서를 개선하는 시간대를 설정해 지속적으로 리팩터링을 진행할 계획이다.