1. 발표 후, 최종 회고

1-1. keep

• 초기부터 gitignore 등을 사용해서 깃허브 컨플릭트 확률이 낮아서 편했고, 좋았던 것 같다.
• 기존 프로젝트보다 커밋을 많이 했고, 풀리퀘스트도 많이 했어서 그 부분이 좋았다.

1-2. problem

• 팀원들끼리 분량 분배나 다른 것들은 많이 소통을 했으나 코딩 방식 통일이 안 되었어서 발표 때 그 부분을 지적을 받은 게 아쉽다.
• 인텔리제이 컨플릭트는 나지 않았으나 테스트 코드 부분에서 개인적인 오류들이 많아서 테스트 코드를 완성하지 못한 문제 등이 있었다.

1-3. try

• 다음 프로젝트 때는 코딩방식 통일 등을 신경쓰고 싶다는 생각이 들었고, 테스트 코드도 작성할 수 있었으면 좋겠다고 생각했다.

2. 내가 앞으로 공부해야 할 것들

일단 무작정 코드를 전부 독파하기엔 힘들다는 판단을 내렸다. 애초에 이미 구현되어 있는 코드의 경우, 단순히 해석하는 것 보다는 새로 내가 써보는 게 나는 이해가 빠른 것 같다.

안 써보면 이게 왜 이렇게 굴러가는지 100% 이해할 수 없고, 그러다보면 결국 공부하는 의미가 없어지기 때문이다.

2-1. 공부할 것들

• QueryDsl

  • 이번에도 나는 QueryDsl을 사용하지 않았다. 진짜 다음에는 데이터 베이스 부분을 빡공해야한다는 생각이 들었다.

• Web socket 등을 이용한 실시간 알림기능

  • 다른 팀원분이 했던 건데 나도 이 부분은 다음에 혼자서라도 해보고 싶다는 생각이 들었다

• Spring Cache를 이용한 시간만료

  • 이 부분도 발표를 하면서 캐시를 사용하면 금전적인 부담이 커진다는 피드백을 받았어서, 어떤 장단점이 있는지 정확히 알기 위해 추가적인 공부를 해야할 거 같다는 생각이 들었다.

• 정적 팩토리 메서드

  • 이번 과제를 하면서 섞여있었고, 그리고 다른 열심히 하시는 분들의 개인세션을 듣다가 알게된 사항인데, 어떻게 돌아가는지 아직 이해할 수 없어서 열심히(?) 공부해보고 싶다.
  • 이 부분은 애매하게 알면서 사용하면 오히려 독이 될 수 있다(?)는 이야기를 다른 열공러님들한테 들었기 때문에 내가 완전히 이해하기 전에는 사용을 지양하고 조금더 빡세게 공부를 해보기로 했다.

• 테스트 코드 작성

  • 테스트 코드는 다른 사항들과 달리 단순한 공부의 시기는 이미 지난 것 같고, 어느정도 이해가 되었으니 성공리에 작성해보는 것이 목표이다.
  • 일단 테스트코드를 작성해보려고 했을 때 느낀 것은 내가 코드 해석을 하는 데에 생각보다 시간이 너무 많이 걸린다는 점이었다. 이 부분을 해소하려면 아무래도 코드를 더 잘 아는 수 밖에 없어서 결국 공부를 더 해야 한다는 결론에 다다랐다.