리얼 월드 스터디 회고 - 2

깃허브 저장소

https://github.com/SeolYoungKim/real-world-study

---

이번 스프린트에서는 게시글의 C,U,D 기능을 구현하였다.

 

아주 간단한 기능의 구현이었음에도 불구하고, 사람마다 이를 받아들이고 해석하는 데는 많은 차이가 있었다. 다양한 아이디어가 있었고, 그 아이디어들이 모두 좋았지만, 그래도 스터디에서 이루고자 하는 목적을 달성하기 위해서는, 스터디원들 모두가 각자의 생각을 모을 필요가 있다고 판단하였다.

 

따라서, 모두의 생각을 좁혀가기 위한 토론을 수행했다.

 

내가 가장 먼저 문제점을 제기했었는데, “명세를 보고 그냥 구현만 하는 기분”이 든다는 문제였다. 리얼월드 자체가 이미 나와있는 명세를 그대로 구현하는 것은 맞지만, 뭔가 애플리케이션의 목적이랄게 없다보니 방향성을 잃는 기분이었기 때문이다.

특히, Post(리얼 월드 상에선 Article) 엔티티의 “description” 필드에 몇 가지 의문이 있었다.

• 이게 무슨 역할을 하는걸까?
• Post는 SNS 상의 글일까? 신문 기사일까? 블로그 글일까?

이러한 의문이 드는 이유는, 리얼 월드로 구현하고자 하는 것이 “무엇인지”를 정의하지 않았기 때문이라는 판단이 들었다.

• 만약 Post(Article)이 신문 기사나 논문같은 글이라면 description 필드가 필요할 것이다.
• 만약 Post(Article)이 SNS의 게시글이라면 description 필드가 필요 없을 것이다.

나는 해당 엔티티를 SNS의 게시글으로써 다루기로 했는데, User를 팔로우 하고, 좋아요를 누를 수 있으며, 팔로우한 유저의 게시글을 모아볼 수 있는 등의 기능이 있었기 때문에 SNS 게시글에 더 가깝다고 생각했다.

이에 대해서는 토론 결과, 아래와 같이 진행하기로 했다.

• 해당 프로젝트는 사이드 프로젝트와는 결이 다른, “스터디”를 위한 프로젝트이다.
• 그렇기 때문에, 사람마다 리얼 월드 명세의 해석 기준이 다를 수 있다.
• 전체적인 큰 틀은 그대로 가져가되, 구현 자체는 자유롭게 수행하자.

다음 토론 주제로는,

• 전체적인 ERD를 그리고 연관관계를 먼저 매핑한 후, 구현을 하느냐
• 이대로 기능을 스프린트 마다 정해서 구현하면서, 추가되는 기능이 있을 경우 그 때 가서 추가하느냐 (요구사항이 변하는 환경을 비슷하게나마 조성(?))

에 대한 것이었다.

 

둘 다 괜찮은 방법이었기 때문에, 스터디원들 모두가 해당 내용을 비교적 오래 고민했다. 하지만, 우리가 진행하는 리얼 월드 구현은 “프로젝트”보다는 “스터디”에 더 가깝다는 판단을 하여, 두 번째 방법으로 수행하기로 했다.

 

토론이 어느정도 마무리 되고, C,U,D 기능을 구현하면서 학습 해볼만한 키워드들을 주고받았다.

• @Transactional 애노테이션이 필요한 이유와 동작 원리
• CG LIB(Proxy)
• JpaRepository 인터페이스가 어떻게 리포지토리로써 동작이 가능한지
• 요청 DTO의 기본 생성자를 private으로 해도 되는 이유
• Controller vs RestController
• @RequestBody
• 단위 테스트

위와 같은 키워드와 간단한 작용 기전에 대한 토론(?)을 수행한 후에, 다음 스프린트에 대한 목표와 일정을 논의했고, 다음 스프린트는 단건 조회 및 전체 조회 + 페이징이다. 기간은 3일로 정했다.

 

느낀 점

사람마다 생각이 너무 다양해서, 여러 의견을 듣는 것이 너무 좋았다. 내가 생각지도 못했던 부분을 찔러주는 느낌? 앞으로도 많이 배워갈 것 같다. 또한, 토론을 통해 다양한 생각을 좁혀가는 것도 좋은 경험이었다.