💻Today's Schedule

09:00 ~ 10:00 CODEKATA
10:00 ~ 12:00 개인 학습
12:00 ~ 13:00 점심 식사
13:00 ~ 14:00 개인 학습
14:00 ~ 17:00 프로젝트 발표
17:00 ~ 18:00 KPT 회고
18:00 ~ 19:00 저녁 식사
19:00 ~ 20:00 베이직반 수강
20:00 ~ 21:00 개인학습

✍ Today I Learned

프로젝트 마무리하기 : 피드백 살펴보기

  • 프로젝트 발표까지 완료했다. 프로젝트를 정리하며 피드백받은 내용을 기록한다
 

GitHub - fargoe/Newsfeed

Contribute to fargoe/Newsfeed development by creating an account on GitHub.

github.com

 

21조 발표 ppt의 사본

뉴스피드 프로젝트 SPRING JAVA 스프링N코드 난... ㄱr끔... 눈물을 흘린 ⊂ト .... ㄱr끔은 눈물을 え占을 수 없는 Łйㄱr 별루⊂ト... ◀ 21조 뉴스피드 발표 나유화 김창민 김도균 이승언 FOLLOW

docs.google.com

 

Figma

Created with Figma

www.figma.com

 

피드백 

피드백 내용은 아래와 같다. 한페이지 가득한 피드백을 받았는데^^..ㅠ 우선 리팩토링이 되지 않은게 가장 큰 문제였던 것같다. 내가 작성한 코드에 대한 피드백만 정리한다. 

- ApplicationException의 ErrorCode에서 HTTP Status Code를 사용합니다. 사용자 인터페이스와 비즈니스 로직의 분리 관점에서 HTTP Status Code와 별도로 코드를 정의해서 사용하면 좋을것 같습니다.
  • ErrorCode는 비즈니스 로직에만 집중하고, HTTP Status는 전역 예외 처리기에서 처리하는 방식으로 수정한다. 이를 통해 하나의 비즈니스 로직이 여러 상황에 맞는 HTTP Status를 유연하게 반환할 수 있다.
- 프로필 이미지를 읽어들이는 비즈니스 로직이 controller에 위치합니다. service에서 처리하면 좋았을것 같습니다. - 필수 요구 사항의 프로필 조회는 내 프로필 조회와 타인 프로필 조회가 있습니다. 타인 프로필 조회를 제공하지 않는것 같습니다.
  • 현재 프로필 이미지를 읽어오는 로직이 Controller에 위치하고 있는데, 이는 Service에서 처리하는 것이 좋다. Controller는 HTTP 요청과 응답만을 담당하고, 비즈니스 로직은 Service 계층에서 관리하는 것이 적절하다.
  • 프로필 이미지를 읽어들이는 로직을 Service로 이동하고, Controller는 이 Service를 호출하는 방식으로 수정한다. 이를 통해 유지보수와 테스트가 쉬워지고, 책임이 분리된다.
  • 타인 프로필 조회에 대한 부분은 이전에 프로젝트를 정리하며 작성했는데, 요구사항과 와이어프레임을 완벽히 숙지하지 못해 마이프로필에 대한 코드 구현을 진행해서 발생했다. 이부분도 리팩토링을 하며 반영해야겠다.
- 비밀번호 변경은 비밀번호 생성과 같은 검증이 동작해야 합니다. (8글자 이상 등등)
  • 이건 리팩토링을 하지 못해 발생한 문제 같다. 비밀번호 변경시 나는 dto에서 유효성 검증을 한 후에 변경되도록 코드를 작성했고, 비밀번호 생성은 회원가입을 담당한 팀원이 서비스에서 검증 로직을 작성했다. 이부분을 일관되게 코드를 수정하는 과정을 거쳤어야 했는데 수정하지 못했다.
- CommentService에서 친구 관계를 확인할때 UserId와 FriendId를 변경하면서 두 번 조회합니다. friendship을 저장할때 이미 양방향을 고려해서 두 개의 레코드를 저장하고 있습니다. 팀 내에 데이터 처리 방식에 대한 공유가 부족했던것 같습니다.
- CommentService의 getComments에서 comment.post를 사용하지 않는데 fetch join을 하는 이유는 무엇일까요?
  • 현재 CommentService에서 친구 관계를 확인할 때 두 번 조회를 하고 있다. 하지만 친구 관계는 이미 양방향으로 저장되고 있으므로, 두 번 조회할 필요가 없다. 친구 관계를 확인할 때 한 번의 쿼리로 처리하도록 수정한다. 이미 양방향으로 저장된 데이터를 조회할 때는, 쿼리 효율성을 높이는 방법을 고려한다.
  • fetch join은 프로젝트를 정리하며 내용을 정리했지만 한번 더 정리하면  초반에 친구관계에 대한 고민을 하며 '친구관계가 끊긴 이후에도 친구 게시물에 작성했던 댓글을 볼 수 있는가?' 에 대한 고민을 하다 작성했었는데 결과적으로는 '친구관계가 끊긴 후에는 작성했던 댓글을 볼 수 없다'로 팀원들과 다시 한번 정의하며 사용하지 않았다. 리팩토링시 이부분도 수정을 진행해야 한다. 

 

개인 KPT회고

 

Keep - 현재 만족하고 있는 부분

- 작업할 도메인별로 분리된 구조가 코드작성과 유지보수 측면에서도 도움이 되었다. 팀원들 간에 명확한 역할 분담이 있었기 때문에 각자가 맡은 기능에 집중할 수 있었고, 의사소통도 명확하게 이루어졌다. 덕분에 각자가 책임감을 가지고 작업에 임할 수 있었으며, 다른 팀원의 코드 변경이 내 작업에 미치는 영향을 최소화할 수 있었다. 이러한 분업 구조가 프로젝트 전반의 속도와 안정성에 긍정적인 영향을 미쳤다.

 

Problem - 불편하게 느끼는 부분

- 도메인별 분리가 초기 코드작성에는 편리했지만 각 팀원이 자신의 도메인에 맞게 코드를 작성하다 보니 코드의 구조나 로직이 서로 상이했고, 이를 파악하는 데 시간이 필요했다. 주석 또한 일관되지 않아 코드를 읽고 이해하는 데 어려움이 있었다.
- 예외 처리에 대한 논의가 부족해 팀원들 간에 일관된 방식으로 처리하지 못해 가독성과 유지보수성이 부족했다. 각자 예외 처리를 독립적으로 구현하다 보니, 예외 처리 방식이 상이했고 이로 인해 예외 처리 로직의 통일성이 떨어져 코드의 일관성을 유지하기 어려웠다.
- 각자 코드를 작성하고 기능 테스트까지는 마쳤지만,  리팩토링은 진행하지 못했다. 프로젝트 기간이 짧았고, 리팩토링에 대한 충분한 논의가 이루어지지 않아서 코드 품질을 개선할 시간이 부족했다.

 

Try - Problem에 대한 해결책, 당장 실행 가능한 것

- 도메인별로 작업을 분리하더라도 코드 작성 시 일관성을 유지할 수 있도록, 코드 컨벤션을 강화하고 예외 처리에 대한 명확한 규칙을 마련해 설계 단계부터 적용해야 한다. 또한, 리팩토링 계획을 세워 코드 품질을 개선할 수 있도록 해야 한다. 이를 통해 서로의 코드를 쉽게 이해하고, 유지보수성을 높일 수 있을 것이다.

 

📝 회고

이게 또 하니까 된다. 물론 피드백 한바가지를 받았지만? 이전의 프로젝트보다 정리된 느낌이 들었다.
그리고 템플릿 코드가 없어서 그런지 진짜 프로젝트를 진행한 느낌이 들기도 했다. 
이전엔 프로젝트가 끝나고 어떤 것을 어떻게 정리해야할지 막막했는데 
이번 프로젝트는 리팩토링을 어떻게 진행해야하고, 어떤 것들을 보완하고 수정해야할지 머릿속에 그려졌다.
그리고 협업에 대해서 좀 더 고민할 수 있었던 프로젝트 였던 것같다. 
내 단점과 장점을 객관화해 바라볼 수 있는 시간이었다. 

🔖 Tomorrow's Goal

  • 프로젝트 정리하기
  • 숙련주차 강의 듣기^^..ㅠ

티스토리툴바