스프린트 4주차 회고

이번 주 목표와 실제 성과 이번 주 목표도 역시 상품 상세 페이지의 완성(저번 주 목표도 완성이였는데.. ) 상품 문의 기능만 하면 상세 페이지는 완성이 되지만 진도로 보면 목표를 굉장히 보수 적으로 잡은 걸로 보이지만 그래도 생각보다 할게 많았다.
먼저 백엔드를 전체적으로 갈아 엎었다. 이유는
1. 테스트 코드를 하나 만들기 위해서 많은 의존성 주입이 필요하고 테스트 자체가 굉장히 난잡 해졌다. 내가 작성했지만 어떤 결과를 원하는 지 잘 모르겠음
2. 상품의 옵션이나 이미지 같은 것들이 모두 Entity였지만 이미지나 옵션은 사실 Entity로 관리할 필요가 없었다.(굳이 Entity를 이용해 다르게 식별할 필요 X) 값 객체(VO)를 사용하면 좀 더 의미가 잘 들어나고 도메인 모델로 사용할 때 보다 훨씬 로직이 간단해진다.
그래서 이대로 진행은 더 어려울 것 같아 의료진과 상담 후 다시 리팩토링을 진행하였다.
그리고 프론트엔드 테스트는 모킹에 대한 두려움에서 일까 좀 기피하는 것 같았지만 테스트 코드 없이 만들어 진 프로젝트는 언제 터질 지 모르는 시한 폭탄이다!. 라는 생각으로 하나 하나 스토어 부터 컴포넌트 테스트 까지 작성을 했다(범위는 줄여도 퀄리티는 포기하지 말자!!).

회개
인수 테스트는 기둥같은 역할이다.
인수 테스트는 사용자 스토리에서 얻는 가치를 소프트웨어로 확인을 하는 테스트 이기 때문에 프로그램에서 가장 중요한 요소 중 하나 라고 할 수 있다. 단위 테스트도 사실 이 인수 테스트를 통과 시키기 위해서 만드는 것이나 마찬가지
벽을 짓는다고 하면 인수테스트는 벽돌같은 역할 이다. 일단 기반이 튼튼해야지 시멘트(단위 테스트)를 바르건 뭘 하건 할 건데 이 인수테스트가 제대로 잡혀 있지 않으면 처음 부터 다시 시작해야 할 수도 있다. 벽돌이 없는데 시멘트부터 바른다고 벽이 세워지지 않는다.
하지만 인수 테스트를 작성하지 않았다. 정작 중요한 것을 놓치고 있었다. 오히려 반대로 단위 테스트의 하위기능으로 인수 테스트가 있는 줄 알았는데 아니였다.

글로 뭔가를 끄적여 놓기는 했지만 코드는 작성하지 않았다. 나중에 해야지 라는 생각으로 하면 테스트를 위한 테스트를 만드는 느낌으로
하기 싫어지니까 사용자 스토리를 토대로 테스트를 작성하고 통과시키는 것 까지를 작업 단위로 잡기

설계 문서가 너무나 빈약하다.
설계와 기획은 계속해서 발전시켜나가야 한다. 그리고 동시에 진행을 해야한다. 하지만 이번 주 작업한 것을 보면 설계설계설계 코딩코딩코딩 방식으로 했다. 아니 설계는 사실 발전시키지 않았다.
설계를 잘하면 설계한 것 을 토대로 받아쓰기 방식으로 쭉쭉 코딩을 해야하는 데 일단은 코드 부터 치고 생각을 하는 이 버릇을 고치도록 하자
설계 문서도 발전 시키고 사용자 스토리를 AS I SO 의 형식으로 업데이트
