1주차와 마찬가지로 KPT 회고 프레임워크를 선택해서 작성해보려고 한다!

Keep(만족, 지속하고 싶은 부분)

이번 2주차는 개인프로젝트에서는 RDB 모델링을 마친 뒤 엔티티를 정의했으며 현재는 조회 API를 만들고 있고, 강의에서는 Presentation Layer에 대한 부분을 수강했다. 강의가 개인프로젝트보다 좀 빠르지만, 그만큼 개인 프로젝트에 적용할 수 있는 부분에 대한 인사이트를 미리 얻어갈 수 있는 것 같아서 좋다.

Problem(부족, 아쉬웠던 부분)

또 내 과욕이 부른 스불재(스스로 불러온 재앙) 느낌의 아쉬운 부분을 써보자면.. RDB를 너무 현업과 비슷하게 만드는 것을 목표로 잡지 않았나 싶다..ㅎㅎ 뭐 어쩌겠어~ 벌린 일이니 해야지..!!

강의에 대한 내용은 아쉬운게 전혀 없다!! JSP에서 Tag(<% %>)가 빠진, Spring 공식 팀에서도 밀고 있는 템플릿 엔진인 Thymeleaf를 잘 알고 계시고, 다시 배워보니 좋았다!

여담으로, Template for Spring으로는 JSP / Thymeleaf / FreeMarker / Groovy Markup / Jade4j / JTE(Java Template Engine) / Velocity / JMustache / Pebble가 있다.

어느것을 택하든 자유이나 Spring에서 공식적으로 Support하고 Advertise하는 제품(라이브러리)를 사용하는 것을 추천한다.

Try(도전, P에 대한 해결책 등으로 다음번에 보완하거나 시도할 부분)

엔티티를 너무 많이 만들고 관계도 1:N, N:1, N:M(을 풀기위한 중간 엔티티) 여러가지를 사용한만큼 JPA를 잘 알고 사용해서 열심히 풀어나가면 되는 문제이고, SSR대신 CSR로 해서 내가 익숙한 Vue보다는 React with TS로 화면을 구성해보려고 한다.

그리고 테스트코드도 좀 더 다양한 방법으로 도전해보면 어떨까싶다(TODO).

예를 들면 TestContainer라던지.. 아니면 MockMVC대신에 RestAssured(또는 RestAssuredMockMvc), WebTestClient등을 사용해볼 수도 있겠고 RestDocs 또는 RestDocs와 Swagger를 함께 사용하는 restdocs-api-spec를 써볼수도 있을 것 같다.

일단 큰 목표는 마음과 머릿속 한켠에 자리를 잡아두고 MVP(Minimum Viable Product)라고 불리는 최소 기능 제품을 만들어서 정상작동하는데 문제가 없는 제품을 만들고 고도화를 통해서 기능개선 또는 기능추가, 사용성개선 등을 생각해보는게 맞지 않나 싶다!