📌 8주차 이후 질문 및 정리
1) 단위테스트, 통합테스트 그리고 UT
단위테스트: class 단위로 Unit을 격리해서 오류를 더 쉽게 찾기 위한 과정을 거치는 테스트통합테스트: 통합환경을 갖추고 Test
정리 블로그: https://velog.io/@mooh2jj/Junit-기본-예제
2) Spring AOP 기능
Load time weaving
compile time weaving: 특정한 함수 호출 전이나 후에 뭔가 공통적인 처리가 필요하다면? AOP라 보면 된다.
ex. 로깅, 트랜잭션, 인증
3) AOP 프록시란?
대상 오브젝트에 Aspect를 적용할 겨우 Advice를 덧붙이기 위해 하는 작업.
CGLIB(Code Generation Library) : 실행 중에 실시간으로 코드를 생성하는 라이브러리 프록시를 사용하여 프록싱 처리를 한다.
- 프록시 request scope도 있다.
비싼작업. JVM 메모리 할당 GC하는 동안 메모리 Locking으로 프로세스가 멈추면 레이턴시가 길어짐.
request scope의 프록시 객체는 CGLIB를 통해 생성된 가짜 프록시 객체임! 실제 빈을 요청하는 위임 로직이 있어 싱글톤 빈처럼 동작함!
: https://velog.io/@mooh2jj/Spring-Proxy
4) ThreadLocal => 로깅할 때! // 조심해야될 작업!
: 쓰레드 로컬을 사용하면 각 쓰레드마다 별도의 내부 저장소를 제공해 동시성 문제 해결
개념 숙지가 부족. AOP 절대로 계륵?같은 개념이 아님, Transaction, 로깅 대표적으로 많이 사용하는 기능도 AOP한 기능임.
5) 기본 스프링 프레임워크 정리는 기술면접 리스트 블로그에 작성해두었다.
: https://velog.io/@mooh2jj/스프링-프레임워크-기술면접-정리
📌 전주(2주치) 개인 공부한 내용들
0) 알려주신 디자인패턴 블로그(https://refactoring.guru/design-patterns/catalog) 정리
: https://velog.io/@mooh2jj/스프링을-위한-디자인패턴-정리
1) 알고리즘 : 문자열, 재귀, 배열 -> 깨달음 점? : 바텀업 방식으로 해야된다는 것 참 지루한 작업
- 문자열 : https://velog.io/@mooh2jj/신규-아이디-추천-문자열문제
- 재귀, 배열 : https://velog.io/@mooh2jj/알고리즘-주요-표현식-정리 중 재귀함수(팩토리얼)
2) SrpingBoot 공부에 중점
- SpringBoot MVC : board 게시판(bootstrap4, thymeleaf, Security,JPA, querydsl) 클론코딩
: https://github.com/mooh2jj/springboot-web-thymeleaf.git - SpringBoot REST API : TodoList(ReactJs, JUnit5 Test) 리팩토링
: https://github.com/mooh2jj/todolist_backend.git
3) <클린코드> 책 : 예외처리, 주석처리, 테스트 중요성, 결국엔 <오브젝트>책 내용이랑 비슷. 클래스를 작게 설계(SRP) 등등
4) 블랙스완 프로젝트 : 기술적 점검
📌 멘토링
1) SpringBoot vs Spring 가장 큰 차이 : 포멧의 단순화
- SpringBoot 임베디드 tomcat 설정 - 프로덕션 상태로 따로 해줘야 된다!
2) 알고리즘 지루한 바텀업 방식에 재밌게 공부하는 방식 질문 -> 큰 의미 없음
3) 오늘 멘토링은 내가 아이디어를 짠 프로젝트를 점검
아이디어 차원에서 얘기하는 건 좋은나 취업을 상정한 프로젝트로는 너무 기술 스택의 초점이 프론트까지 간것 같다는 피드백을 주심. scope 좁게.
4) 기존 프로젝트 참조 - 분산시스템을 어떻게 설계할 것인가?
5) 프로젝트의 핵심 기능 정하기 : 예약, 스케쥴러, newsfeed
6) 중요 엔티티 설정 : StudyGroup, Reservation, Room
그 바탕으로 ERD 설계하기
8) 분산시스템의 대한 토론
- scale up vs scale out
- measuerable한 수치를 가지고 얘기(ex. QPS, Thread 할당 보장수)
- read or write 중 비율이 무엇이 더 높을지 산정
- 뉴스피드 방식으로 push or pull 방식 고려하기
- 리마인드 : 스케쥴러 또는 이벤트브릿지 기능으로 무엇을 선택할지 산정(spring batch-mail 건의)
- 예약시 스케쥴이 overlap될 수 있는 문제시 키설계 고민할 것
- AWS 인스턴스 -> 네이버 클라우드 인스턴스로
9) 문서화 작업(github으로 MD로 정리)
- requirement(요구사항) - 사용자 기준으로 : UseCase
- API 명세서 - 설계작업 전 작성해야하는 것
- ERD 설계
- 캐싱작업 타겟 : 예약 리스트
10) 주석 처리
- 클린코드 책보면서 주석처리 질문 : 주석은 협의하에. 사람들이 알아보는 것이 중요. 알아보는 것을 목표로 디테일해도 상관없음.
📌 느낀점
멘토님과 <ward-study 프로젝트> 기술면접식으로 질문과 답변이 오갔다. 예상대로 역시나 빡셌다..
1) mesaure한 수치에 대한 얘기를 한다는 게 너무나 힘듦.
QPS, TPS 등 사용자수가 하루에 얼마나 이용하고 또 1초에 몇번 request가 오갈지에 대한 산정이 꼭 필요하고 설계해야한다고 뼈때리는 조언을 주셨다. (현재 나로서는 너무 설계조건을 파악한다는 게 너무 힘들었음.)
2) 기술 스택 산정에 대한 어려움
일단 중요 핵심 기능으로 예약, 스케쥴, 뉴스피드 로 정해졌다. 그중 스케쥴기능으로 이를 위한 기술 스택으로 비동기 메시징 큐 방식이 진행될지 궁금했다. 하지만 이럴만한 이유가 있는지 다시 한번 물으니 할말이 없었다. 내가 단순히 하고 싶다는 이유만으로 기술오버스택이 되는 문제를 너무 간과한 건 아닌지 고민하게 되었다.
3) 프로젝트 진행에 있어서 고민점이 한둘이 아니다. 그외 문서화 작업은 어떻게 해야할지.. git branch 정리는 어떻게 해야할지 고민하고 생각해야 될게 너무 많아보였다. 솔직히 나혼자 처리해야 되는 상황이니 커뮤니케이션 비용이 줄어들어서 장점이지만 반대로 혼자이니 모든 걸 다 처리해야 하는 상황이 굉장히 부담이 많이 되었다.
📌 해야 할 것
- 코딩 테스트 , 자료구조 알고리즘 - 기본 책 다시 정리 그리고 코딩테스트 내용 정리
- 멘토님께서 질문하셨던 내용들 블로그 정리
- 스터디 모임 잠정 중단, 프로젝트에 집중할 것. 관련 기술 스택과 필요 작업 실행
- 운동 PT - 상체 푸쉬업 많이 내려서 함!+ 어깨 + 광배근 스미스 머신!
