자바, 코틀린 사용시 Object JSON 변환간에 ObjectMapper를 많이 사용한다. // Object -> JSONUser user = new User("John", 25);String json = objectMapper.writeValueAsString(user);// JSON -> ObjectUser user = objectMapper.readValue(json, User.class); 성능이 중요한 애플리케이션에서 ObjectMapper는 조심해서 사용해야 한다.왜냐하면 내부적으로 자바의 리플렉션을 사용하여 변환해주기 때문이다. 리플렉션이 안좋은 이유는 두가지 문제가 있다1. JIT(Just-In-Time) 컴파일러의 최적화를 제대로 활용할 수 없다.JIT 컴파일러는 실행 시간을 단축하기..
개요로컬 혹은 CI 서버에서 실제 운영 환경과 같은 디비를 사용하여 통합 테스트를 하고 싶어 TestContainers 설정을 적용했다.세부 설정은 docker-compose.yml로 관리하는게 편하여 이를 import하는 방식으로 구현했다. 환경스프링 부트 3.2.6Gradle 8.8자바 17 설정gradle에 라이브러리 추가ext { testcontainersVersion = "1.19.0"}dependencies { testImplementation "org.springframework.boot:spring-boot-testcontainers" testImplementation 'org.testcontainers:mysql' testImplementation 'org.sprin..
이번 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. 최종 목표 배지최소 레드 배지 이상
외부설정 문서화 yml 혹은 properties 파일에 프로퍼티 설정시 SpringBoot에 이미 정의되어 있는 document랑 자동완성을 확인할 수 있다. 개발자가 커스텀한 값들에 대해서도 문서랑 자동완성ㅇ을 지원하는 방법에 대해 알아보자. Spring Configuration Processor란? application.properties, application.yml 파일 등에 넣는 커스텀 설정의 자동 완성, 도움말 등을 지원해주는 도구이다. 실습 환경 Spring Boot 3.2.0 Gradle 8.2 라이브러리 의존성 추가 dependencies { annotationProcessor 'org.springframework.boot:spring-boot-configuration-processor'..
면접에서 아래 코드에 대한 구조 리뷰를 요청 받았습니다. @Service @Transactional(readOnly = true) public class StationService { private StationRepository stationRepository; public StationService(StationRepository stationRepository) { this.stationRepository = stationRepository; } @Transactional public StationResponse saveStation(StationRequest stationRequest) { Station station = stationRepository.save(new Station(station..