최근 계속해서 테스트의 중요성과 TDD를 학습하면서 Test 관련 내용을 공부하고 있습니다. 지금까지는 다양한 테스트 도구의 사용법을 익혔는데, '이를 좀 잘 정리할 방법이 없을까?'라고 생각하다가 여윽시 근본은 공식문서라는 생각이 들어서 번역겸 정리를 해보고자 합니다. 또한 인프콘 세션을 정리하면서 결국 테스트를 통해 spring 본연의 기능을 더 깊이 있게 이해할 수 있다고 판단했습니다. 공식문서 목차 Introduction to Spring Testing Unit Testing Integration Testing JDBC Testing Support Spring TestContext Framework WebTestClient MockMvc Testing Client Applications Appen..

테스트 방법론에 대한 공부를 하면서 인프콘 세션 중 '나도 내 코드의 문제를 찾고 싶다구요?! - 테스트 할 때 기억할 7가지, 한주승' 제목의 세션을 보게되었습니다. 테스트의 중요성은 정말 아무리 강조해도 부족하지 않습니다. 직접 경험한 이야기를 좀 적어보겠습니다. 맨 처음 아무것도 모르는 상태에서 입사를 했을 때, 테스트 코드가 없이 개발되었던 어플리케이션을 인수인계 받은 경험이 있습니다. (제가 말하는 테스트 코드는 코드로서 작성된 코드를 테스트하는 코드를 말합니다.) 통합테스트가 가능한 형태로만 별도의 프로세스 형태로 테스트 프로그램만 존재했습니다. 이런 상황에서 간단한 기능을 개발하고 배포할 때도 긴장되는 순간도 많았고, 신규 개발에 대한 테스트만 추가하더라도 다른 모듈의 종속성 때문에 관련된 ..

최근 하나의 모듈로 개발했던 프로젝트를 멀티 모듈로 분할을 진행하면서 과연 올바른 방법으로 멀티모듈이 설계가 된건가... 라는 물음과 이게 과연 적절한 것인가...하는 물음이 발생했습니다. 자료를 찾아보면서 다시금 정리를 해본바... '싹다 갈아 엎을까?'라는 생각이 많이 들고 있습니다. 개인적인 경험으로 보았을 때, 멀티 모듈을 구성하는 이유(분산 아키텍처를 수용하는 이유)는 두가지라고 생각합니다. 단일 실패지점(SPOF)에 의해 전체 시스템이 마비가 되는 것을 방지 높은 응집도와 낮은 결합도를 가지고 유지보수성 증가 그래서 적용은 해보고 싶은데, 참 어렵습니다. 그래서 멘토링 경험을 계기로 인프콘 세션 중 '실전!멀티 모듈 프로젝트 구조와 설계' 라는 주제로 네이버 김대성님이 발표해주신 세션 내용을 ..

2022년 하반기, 이직을 준비하며 여러 도서를 단기간에 줄줄줄 읽어내려갔습니다. 물론 다 알지는 못합니다... 시간적인 이유로 기록을 등한시 할 수밖에 없어서 이렇게 INDEX 기반으로 정리하고자 합니다. 면접이라는 제한된 시간 내에 단편적인 대답을 하는 모범 답안들은 인터넷에 많지만, 개인적으로 공식문서나 발간된 도서들 기준으로 키워드를 정리해보고자 정리합니다. 키워드 분류 체계 언어 : C, C++, C#, PHP, Rust, Java, Kotlin, Python, Ruby, JS, TS 프레임워크 Spring : Core, Testing, Data Access, Web Servlet, Web Reactive, Integration, Languages, Appendix, wiki NestJS OS ..

아키텍처를 설계하는 행위가 아니더라도, 어플리케이션을 설계하거나 모듈 설계 등 설계라는 행위에서 기본적으로 고려해야 될 것이 분할이라는 생각이 많이 듭니다. 특히 지속가능성(관리, 보수 등)을 고려했을 때 논리적 설계를 MECE하게 정의를 잘 하면 잘 할수록 그로인한 이익이 매우 커지기 때문입니다. 카카오 기술 블로그와 SK C&C에서 DDD를 적용하는 과정을 보면서 분할이라는 개념을 정말 '잘!' 이해하여야 한다고 생각했고, 최근 하나의 어플리케이션 프로세스를 멀티모듈로 나누는 과정에서 분할의 어려움을 느꼈기에 기본적인 분할의 개념을 한번 정리해보고자 합니다. 수직적 분할과 횡적(수평적) 분할 일반적으로 분할을 한다고하면 수평적(Horizontal Slicing), 수직적 분할(Vertical Slic..

학습동기 예전부터 알고도 있었고, if kakao에서 아파치 플링크와 함께 로그 분석에 사용했다고하여, 간단히 producer, broker, consumer 구성으로 엇비슷하게 로그를 파싱하여 분산 프로세스별로 토픽을 나눠 broker에 저장하고, 검증이 필요한 프로세스별로 필요한 로그만 comsumer가 소비하여 기능 검증을 위한 로직을 만들어 본 경험도 있습니다. 하지만 그때는 제가 개발한 범위에서 kafka까지 써가며 그렇게 해야되는가? 라는 물음이 있었습니다. 규모가 작은데 별도의 broker 인스턴스까지 띄워서 처리를 해야하나 하는 것이었고, 프로그램이 죽지 않는다면 하나의 어플리케이션 내에서도 멀티스레드와 이벤트 큐를 활용해서 충분히 구현히 가능하기 때문이라 판단했습니다. 그러나 최근 어느정..