이번 4주차는 3주차에 만든 문서를 기반으로 콘서트 예약 서비스에 주어진 요구사항 개발을 시작한다 구현할 API는 크게 다섯가지가 있다.유저 토큰 발급 API예약 가능 날짜 / 좌석 API좌석 예약 요청 API잔액 충전 / 조회 API결제 API대기열을 하는 이유대기열을 하는 이유는 무엇일까?유량 제어를 하기 위함이다. 유량 제어를 하는 이유는 흐름을 제어하는 것을 의미한다.즉, 트래픽이 몰릴 경우를 대비하여 이를 제어하고 디비의 부하를 막는것이 목적이다. 부하의 종류는 읽기 부하와 쓰기 부하가 있고, 부하의 대상은 CPU, 메모리, 디스크가 있다.부하에 대해서도 생각을 해야 한다. 가령 메이플에서 몬스터를 때릴때마다 디비에 데이터를 삽입하면 디비의 쓰기 부하가 많을 것이다.그렇다면 메모리에 저장하고, ..
1~2주차는 TDD와 클린 아키텍처를 학습 하고 작은 요구사항을 구현하면서 익숙해지는 과정이였다.3주차가 본격적인 프로젝트의 시작이였다.장난감 프로젝트용 시나리오를 하나 선택한 뒤, 실제 대규모 서비스 회사에서 경험할 수 있는 일들인 동시성 처리, 메시지 큐, AWS 인프라 구축, 장애 대응 등 직접 체험하면서 점진적으로 고도화 해가는 과정을 경험할 수 있다. 3주차 과제는 다음과 같다.시나리오 선택 및 분석3~5주차 마일스톤 작성시퀀스 다이어그램 작성API 명세서 작성Mock API 작성ERD 설계서비스 시나리오 선택e-커머스 서비스와 콘서트 예약 서비스 두개가 있었다. e-커머스 서비스는 상품 주문 서비스를 구현하는 것이였다.Key Point는 주문에 대한 동시성 처리와 재고 관리였다. 콘서트 예약 ..
다양한 아키텍처를 알아야 할까?모두 적용하는 건 아니지만 학습은 해야 한다아키텍처는 준수해야 하는 제약을 넣는 것이라 볼 수 있다.단순히 요구사항을 만족하는 기능을 개발하고 끝나는게 아니라, 앞으로 유지보수 가능하고 지속적으로 성장 가능한 구조를 고민해야 한다. 이를 위해선 규칙이 필요하여 이러한 규칙은 아키텍처를 학습하고 적용하여 지킬 수 있다.좋은 아키 텍처 패턴은지속적으로 성장 가능한 안정적인 소프트웨어를 잡기 위한 가이드 라인지켜야 할 기본적인 개발 가이드 라인을 잡아주는 틀클린 코드의 중요성비즈니스 로직의 복잡할 수록 코드도 복잡해 진다. 구현에만 초점을 맞춘다면 하나의 클래스에 10,000줄이 넘는 코드가 작성될 수도 있고 하나의 메서드에서 코드의 depth가 10 depth가 넘어갈 수도 있..
Why TDD?소프트웨어 규모가 커지면서 소프트웨어의 품질을 지속적으로 유지시키고 향상시키기 위해선 테스트 자동화의 중요성은 강조되고 있다.TDD는 유지보수 및 장애 발생시 대처를 유연하게 할 수 있는 방법론으로도 볼 수 있다.즉, 빠른 변화에도 유연하게 새로운 기능을 적용하고 변경할 수 있는 기반을 TDD를 통해서 다질 수 있다.테스트 코드 작성은 대부분 동의 하겠지만, TDD에 대한 반대 의견도 많다. TDD가 100% 좋다고는 할 순 없지만 좋은 방법론 중에 하나임은 틀림 없다.테스트 시나리오 및 케이스처음에 정한 테스트 시나리오를 바꾸지 않는 것이 Best지만, 처음부터 완벽한 시나리오를 짜는 것은 힘들다. TDD의 목표 중 하나는 좋은 소프트웨어를 설계하는 것이기 때문에 테스트 시나리오는 언제든..
1. 지금까지의 회고 2. 항해 플러스 참여 계기향해 플러스에서 지원해주는 모든 자원을 활용하여 경험해 보지 못한 기술을 배우고 많은 사람들과 함께 공부하고 성장하고 싶다. 3. 향후 5년뒤 커리어 방향성개발팀을 리드할 수 있는 개발 역량을 키우고 싶다. 4. 10주간의 목표큰돈을 투자한 만큼 그 이상의 배움을 얻어 가고 싶다.모든 미션을 pass한다는 마음가짐으로 과정을 진행한다. 5. 최종 목표 배지최소 레드 배지 이상