- 테스트
- 커버리지 100%가 무조건 좋은 것은 아님
- 문서화
- 프론트랑 협업하니, 백단보다는 API 문서 빨리 해주는 것이 좋음
- 댓글
- 설계에서 고민할 것이 많아서 좋음
- 채팅
- 스프링에 소켓IO 구현해보는것 좋음
- 모니터링
- 모니터링은 어떤걸 생각하고 있는지?
- AWS 클라우드 워치 도입 생각해보고 있음
- 부하테스트 매우 좋다 백앤드 개발자라면 개념에 대해서 알면 좋다
- 배치
- 배치 서비스가 없는 서비스가 없긴 함
- 백에서 스케줄링해서 돌아가야 하는 서비스가 있음
- 좀 더 많이 생각해봐야 할 듯
- 실무에 가면 가장 처음 맡는일이 배치일 가능성이 높다
- 따로 돌아서 윗사람들이 신입들 시키기 쉬움
- air flow?
- 대기업들은 많이 쓴다
- 스프링 진영에서도 비슷한걸 제공하긴 하지만, 상용화까지는 힘듦
- 그래도 쓰는곳이 있긴 함 - 카카오페이?
- spring cloud data flow..
- Redis
- 많이들 쓴다
- JWT 토큰같은거 access 토큰, refresh 토큰 등..
- 요즘은 refresh 토큰도 없애는 중
- 해보면 괜찮을것 같긴 함
- jwt 토큰이 어려우면 세션같은것도 레디스에 담았다 처리할 수 있을것같긴한데 이게 더 어려울 수 있음
- 서비스에서 redis가 필요한 영역 - 보통 캐시역할로 많이 사용한다
- MQ
- 서비스가 나오고 생각해봐야 할 듯
- 결제서비스
- 의도는 좋지만 결제 쉽지 않다..
- 한다고 한다면 포인트의 개념으로 가는게 좋을 것 같다
- 차감하는 방식으로
- 서비스 안에서만 사이클을 돌릴 수 있을 것 같다.
- 게임처럼 내부적으로 얻을수도 있는 방식으로~~
- DB에 문제가 생긴다 → Transaction에 대한 공부 필요하다
- Lock
- 멀티모듈
- 구현하기는 쉬울수 있는데, 개념적으로 어려울 수 있음
- 회사가면 웬만하면 할 것, 추후에는 학습해야 하는 내용이긴 함
스프링 부트를 쓰는데 멀티모듈을 안한다? 빠르게 딴곳을 알아보는게….- 설계하거나 리드해줄 사람이 없어서 IT 기업이라 보기 힘듦
- 이런걸 해줄 수 있는 사람이 회사에 있어야..
- 하나의 서비스 - 연관된 플젝이 4~5개가 있는데, 관리도 힘들고 배포도 힘듦
- 체크한 부분들만 해도 성공적인 플젝이라고 생각하심
백앤드 소양 - 도커는 다룰줄 아는게 좋을 듯 하다
var
- 타입추론 - 코드 분석하는 입장에서는 가독성이 좋지는 않다고 생각하심
- 내부적인 로직에 신경안쓰는? 가져다 쓰는 사람들? 시그니쳐만 알면 되니까
- 라이브러리성 클래스라면 막써도 되지 않을까?
- 비즈니스적인 로직이면 피할 듯 하다
데이터베이스를 학습할 때 속도를 측정한다라고 말할 수 있는 기준- 실무에서 데이터 조회할때 조금 많으면 100만건
- 어느정도 규모 있다 하면 500만건이 기본적으로 넘어감
- 대기업에서 데이터 핸들링이 필요하다 → 1000만건
DB 학습은 준비 과정에 대한 비용이 있어 평소에 준비 해놓는 것이 좋음- 컨테이너 하나 이미지 띄워놓고 테이블 생성할 수 있게, 더미데이터 생성할 수 있게
- 더미데이터 생성해주는 사이트 있어서
- 쿼리 날리는거 연습하기
- 테이블 설계 많이 해보고 데이터 많이 넘겨보고 해봐야 댐
- 실무 데이터 가지고 연습하는게 제일 좋음
- insert 안날리고 select만 할거니까..
- db 덤프떠서 복구해주는 사람이 있을 것임
- 쿼리는 어려움..
샘플코드 가득 차야함! 굿
레퍼런스 가지고 바로바로 써먹으면 좋음
프로젝트 개요
- 이건 어케든 만들어 지긴 할 것
프로젝트 수행결과, 자체 평가 의견
- 이게 우리에게 중요함
협업에 대한 기본적인 것은 연습이 됐다고 생각하고
최종때는 그것을 기반으로 구현하면서 트러블 슈팅
구현방식 - 지금 상황에서 왜 그게 최선의 방법이었는지
다른 방법과 비교해서 어떤게 더 나았는지 정리하면서
요구사항 완결성 - 중요!
- 추려내고 기한내에 만드는 것 1순위
면접때도 질문이 들어올 수 있는 부분, 잘 정리하자!