📚 배운 것(Learned)

• 1차 프로젝트까지는, 서비스의 요구 사항만 명세서와 이에 따른 시나리오를 작성하고 구현하다보면 프론트에선 어떤 식으로 일어날까를 크게 고민하지 않았었다.

  최종 프로젝트에는 프론트와의 협업을 하며 프론트에서의 기획에 따라서도 백엔드는 이에 대해 어떤 식으로 유연하게 변경하고 바꿀 수 있을까 를 생각하게 되었다.

  • 1차 프로젝트 때에는 응답으로 보내줄 DTO 몇 개 만을 작성하고 추상적으로 이 정도의 DTO 로 충분하다고 결론 지은 경우가 많았습니다. 하지만 프론트와의 협업과정에서 비슷한 종류의 도메인을 사용함에도 전달해줘야 하는 DTO 의 종류가 많아졌습니다. 이에 따라 프론트 요구 사항이 변하더라도 DTO 간의 변경 파급효과를 줄 이기 위해, 비슷한 정보를 담은 객체더라도 도메인별로 DTO 를 모두 분리하여 설계하고자 하였습니다.
    • ex: (책 정보 → SimpleBook(책이라는 도메인과 강하게 엮인 api에서 전달할 책 데이터)( 책 목록만을 받아오는 경우 ), StudyBookInfo(스터디 에 강하게 엮인 api 에서 전달할 책 데이터)( 스터디를 조회할 때, 해당 스터디의 주제인 책에 대한 데이터) )

😍 좋았던 것(Liked)

• 솔직히 내가 만들던 것보다 훨씬 예쁜 화면에서 백엔드에서 작성한 api 가 동작하는 것을 보는 것이 가장 좋았다 ㅎㅎ
• 프론트와 기획 단계에서 가장 많은 대화를 나누고 함께 서비스를 만들어 갔다. 이 과정에서 각자가 중요시 여기는 것이 조금씩 다르다는 것을 느낄 수 있었다. 하지만 종국적인 목표는 우리의 서비스가 어떤 것을 제공하고 사용자 경험상 어떤 것이 좋을까 였기에 이를 함께 고민하면서 서로의 생각들을 이해하고 타협하는 경험을 할 수 있어 좋았다.
• 이번에 많은 공통모듈을 만들어두고 시작했던 것이 좋았다. 무엇보다 테스트 코드 작성시에 restdocs 를 사용함에 따라 공통으로 작성되는 부분들이 많았는데 이에 대한 템플릿을 두고 테스트를 작성하니 테스트 코드 작성이 간편해져 좋았다.
• jacoco 를 사용하여 테스트 커버리지를 충족하며 작성한 것이 좋았다. 1차 스프린트는 개발 속도를 위해 60 프로 를 설정하여 진행하였는데, 이 과정에서 테스트 커버리지의 범위에 대한 고민과, 작성한 커스텀 예외들을 위해서도 평소에 작성이 부족했던 실패 테스트들도 작성을 하며 조금 더 안심하며 코드를 작성할 수 있어 좋았다.

💦 부족했던 것(Lacked)

• 초반에 시나리오를 충분히 작성하지 못했다. 따라서 구현을 하면서 여러가지 시나리오가 빠져있음을 알게 된 경우가 많았다.
• 작업 속도가 빠르지 못했다.

🕯 바라는 것(Longed for)

• 여러가지 검증 로직이 현재 부족하다(역시 1차스프린트 시간부족문제 ㅠㅠ). 이에 따라 에러도 상당히 불친절하게 일어나고 있다. (로그 조차도 불친절하다;) 이로인해 가장 큰 문제가, { 프론트 측에서 “서버 에러가 나요" 라는 질문이들어오고 → 서버에서는 “어떤 요청하셨죠??” → “로그 확인해봅시다" →그런데 로그가 없네요 }ㄷ ㄷ .. 라는 상황이 반복된 것이다.
  • 따라서 검증로직 작성을 통해, 조금 더 친절한 에러를 통해 실제 프론트와 백 사이의 의사소통이 오가지 않고, 서버와 프론트 모두의 트러블 슈팅 속도를 증진시키는 것이 필요하다고 생각된다.