최종 피드백

피드백 내용

피드백 내용을 고쳐야할 점과 단순히 아쉬운 부분에 따라 순서를 변경해보았다.

 

---

 

 

개인 과제 직접 구현하는게 쉽지 않을 수도 있는데 완성하느라 고생하셨습니다.

 

반드시 고쳐야 할 점

 

 

1. rest api 설계에는 어느정도 업계에서 사용하는 규칙이 있습니다.
   이를 엄격히 사용하기 보단 케이스에 따라 유동적으로 사용하긴 하는데 기본적인 원칙을 지키는게 좋습니다.
 

->  API 명세를 신경써서 준비하지 못한게 아쉽다. 다음 프로젝트에서는 노력을 기울여 작성하겠다고 반성한다.

 

 

2. git 사용도 적절하지만 커밋 제목을 어떤기능을 구현했는지를 적는게 좋을 것 같네요

 

-> 매 프로젝트에서 지적받는 커밋메세지.

    이번엔 내용을 제대로 적었다고 생각했는데 커밋메세지 양식을 찾아 보니 어림도 없다는 걸 깨달았다.
    그나마 다행인건 현재 진행중인 개인프로젝트에서는 제대로 커밋메세지를 적고 있다는 점이다.

 

 

3. 아쉬운 점은 post같이 단수형보단 posts로 복수형으로 사용합니다.
   단건 게시글 조회는 /posts/{postId}, 전체 게시글은 /posts 로 구성하면 됩니다.

 

-> 기본적으로 URL 작성 양식이 있는지 모르고 임의로 변형하여 작성하였는데 복수형으로 사용해야한다는 것을 배웠다.

 

---

 

 

시간에 쫓겨 깔끔하게 작성하지 못한 코드에 대한 피드백

 

 

 

1. 또한 전체적으로 헤더 설정은 불필요해 보입니다

 

2. update, delete등은 url에 들어갈 필요가 없습니다

 

3. json 활용 버전은 왜 필요한 것인가요!? 필요하지 않을 것 같네요

 

4. repository에 @repository 명시해주는게 좋습니다     

   

 

->  4번은 진짜 실수라서 이걸 보자마자 머리가 멍했다. 내가 안했다고?

 

 

---

 

 

 

앞으로의 발전에 대한 피드백

 

 

1. 용도별로 dto 나눈 것 좋습니다. 처음엔 롬복보다 직접 구현하는게 좋을 것 같습니다 getter setter 생성자

 

2. 전체적으로 서비스에 트랜잭션 선언 필요합니다. 또한 서비스 로직등은 나쁘지 않아보이고 예외처리도 적절해 보이네요

 

 

 

기존의 코드에서는 게시물 수정에만 트랜잭션을 달아두었는데  전체적으로 선언이 필요하다 하시니 약간 멘붕이 왔다.

대체 어디 달아야하지?

그래서 튜터님께 질문을 하여 알아보았다.

 

기본적으로 비즈니스로직 중에  여러개를 삭제하는 메소드는 반드시 트랜잭션을 걸어줘야한다.

 

그런데

하나씩 삭제하는것은 트랜잭션을 걸지 않아도 된다.  (선택사항)

또한 하나를 저장하는것은 굳이 걸지 않는다.  (선택사항)  대신 다른 쿼리문과 엮일 경우 반드시 걸어주도록 한다.

 

개인의 코딩스타일에 따라 실용성을 추구한다면  선택사항에 대해 트랜잭션을 걸지 않을 수도 있고,

에러없는 완벽한 동작을 위해서는 서비스에 전체적으로 트랜잭션을 걸 수도 있다.

 

아직까진 자의적판단이 어려운 실력이기 때문에  어느쪽을 택해야 할지 잘 모르겠다.