2023.05.15 ~ 2023.05.21
5월 15일 (월)
오늘 한 일
- 오전 9시 정규 회의 → 각자 진행사항 발표
- 위시리스트 CRUD 기능 추가
- 동시성 제어 알아보기
- Enum List 매핑하는법 알아보기 @ElementCollection 알아보기
5월 16일 (화)
오늘 한 일
- 기술매니저님 멘토링
- 아키텍처 (레이어드, 헥사고날)
- 동시성 제어
- 예약 api backend에서만 완성
- JPA, JPQL, QueryDSL
내일 할 일
5월 17일 (수)
오늘 한 일
- Filter, Interceptor, AOP의 흐름
- 동시성제어 synchronized, lock
- Requestpart requestparam
- 단방향 연관관계 manytoOne ondelete
- querydsl jpqlQuery
- xss
- 발표준비
5월 18일 (목)
오늘 한 일
오늘은 클론 프로젝트 발표날이다. 이번 프로젝트 때 얻어간게 없는 것 같아서 여러 팀들 피드백을 주워 담아보았다.
- 근거와 이유를 가지고 라이브러리를 선택
- 백엔드쪽 S3 connection 원인이 그것이 맞은지 → 설명이 필요함
- 양방향 stackoverFlow → 꼭 jsonignore 만 해결할 수 있었는지
- 시간이 남았을 때 더 많이 시도해보았을 것을 검토 → 뭘 더 해볼 수 있었는지
- 아키텍쳐 구조생각해보기
- modelAttribute or RequestPart → 꼭 같이 보내야 하는가? 이미지 S3 업로드했을 때 따로 API가 있기 때문에 handling 도 따로 해줄 수 있다.
- modelAttirbute → view 모델과 같이 쓰는게 일반적이다 보니
- 이미지 중복처리 → 같은 이미지일경우 파일 등록 수를 줄일 수 있도록
- 이미지 image.getOriginalFilename.replaceAll ( 정규표현식 ) 부분에서 뒤에서부터 . 을 찾아서 Substring 하거나 정규표현식을 아예 안쓰는 방법을 찾기 → 정규표현식이 무겁기 떄문
- 파일 크기 re-sizing 생각하기
- new (새로운게시물) logic 만들어보기
- 알림기능
- papago api 언어번역
- 왜 이러한 기술을 도입했는지에 대한 고민, 프로젝트에서 중요하게 생각했던점이 무엇인지
- 트러블슈팅 → 어려가지 대안을 내놓고 한가지를 선택한 이유
- 정규표현식 테스트 코드를 짜거나
- token @NotBlank 동적 체크 하기
- 의미없는 코드 남기지 않기
- 스케쥴러 알아보기 → 예를들어 refㄹresh 토큰이나 12시가 됐을 때 db에 남겨진 만료된 토큰들을 지워주는
- 보통 테스트를 위한 DB를 따로 만들어서 테스트 한다. → Transactional을 달아줘야 될 때면,
5월 19일 (금)
오늘 한 일
- 실전 프로젝트 시작
- 챌린지 주제 회의
- 채용공고 우대사항 조사해서 가져가야할 기술스택 정리
- OAuth
- Spring Security
- 대용량 데이터 처리를 위한 아키텍쳐 및 데이터베이스 구성에 대한 이해도가 있으신분
- 대규모 트래픽 처리 및 고가용성 처리 경험
- Redis 실무 적용경험이 있는 분
- MongoDB 실무 적용 경험이 있는 분
- JPA 와 같은 ORM 사용 및 도메인 모델링 경험이 있으신 분
- 클라우드(AWS, Kubernetes 등)를 사용해 본 경험
- 유닛 테스트, 통합 테스트 작성 경험
- 시스템 모니터링 및 알람 구성 경험
- 주제: 대규모 채팅 시스템 트래픽
5월 20일 (토)
오늘 한 일
- 채팅 대규모 트래픽 처리 관련 지식 정리
- 대규모 채팅 시스템 설계
- SA 작성
5월 21일 (일)
일주일 회고
클론 프로젝트가 마무리 되면서 가장 아쉬웠던 점은 내가 짜지 않은 코드를 이해하는게 어려웠다는 점인 것 같다. 1주일이라는 짧은 시간안에 각자가 2~3일 공부하면서 새로운 기술을 도입해서 구현한 코드를 단번에 이해하는게 말이 되지도 않는다. 팀원의 코드를 뜯어보면서 사용했던 기술에 대해서 개인적으로 공부해야 하는데 시간이 넉넉하지 못했다.
이번 프로젝트에서 내가 가져간 점이라면 흐름만 알며 사용했던 Security에 대해서 우리 프로젝트에 맞게 사용하기 위해 고쳐보면서 이해해봤던 점인 것 같다.
아쉬웠던 점은 동시성 테스트가 필요한 기능들이 구현이 되지 못한 채 테스트 코드로만 확인할 수 있었던점이라고 해야하나.. 사실 테스트 코드도 정확한지 이해가 되지 못했다. 메서드단에 synchronize 를 걸고 repository에 비관적 lock을 걸어 데이터를 제어해서 해결했다는 점밖에 이해하지 못한 것 같다. 데이터 자체에 락을 잡기 때문에 읽기가 많이 이루어지는 데이터베이스의 경우 손해가 더 크다고 알고 있는데 이 부분에 대해서 더 좋은 해결법을 찾지 못했던 것 같다.
서비스 프로젝트가 마무리 되면서 이번 주 부터 백엔드 4명이서 기술적 해결에 초점을 맞춘 6주 실전 프로젝트인 챌린지가 시작되었는데 서비스 구현을 많이 못해본 것 같아 아쉽다. 그래도 oauth와 websocket 을 사용하면서 채팅 시스템을 주제로 잡아 어느정도 배우고 싶었던 기술들을 공부할 수 있을 것 같아 다행이라고 생각한다!