Topic
테스트와 품질
시간이 지나도 의도를 지키는 테스트, 리팩터링, 정적 분석과 품질 실천을 다룹니다.
공통 모듈의 함정: 구체적인 기능으로 코드를 응집하라
소유권이 드러날 때까지 공통 모듈을 늦추고, 로깅·예외·공유 규격을 구체적인 기능과 책임 중심으로 묶는 방법을 다룬다.
거대한 서비스 클래스를 책임 단위로 나누는 법
개념 지도, 책임의 흐름, 테스트 경계, 구체적인 리팩터링 대안을 통해 비대해진 서비스 클래스를 나누는 방법을 설명한다.
코어를 깨끗하게 지키는 의도적인 오염 경계
피할 수 없는 복잡성을 명시적인 외부 경계에 가두고, 제한된 개발 시간을 시스템의 핵심 개념에 쓰는 방법을 다룬다.
사람이 이해하고 빌드가 지키는 레이어 규칙
안정적인 레이어 역할과 선택적 상위 레이어의 조건을 정의하고, 필요할 때만 자동 검증으로 규칙을 강제하는 방법을 다룬다.
Reader, Finder, Searcher를 행위로 구분하는 법
Reader, Finder, Searcher를 조회 건수가 아니라 직접 읽기, 추가 필터링, 복합 검색이라는 행위로 구분하는 기준을 설명한다.
추상화는 구현 뒤에 온다: Service와 Impl 관행 다시 보기
구체적인 구현에서 검증된 공통점을 추출하고, 구현체가 하나여도 실제 경계를 만드는 인터페이스만 남기는 설계 기준을 다룬다.
불필요한 조회 없이 권한 검증을 설계하는 법
로그인 사용자를 한 번만 확인하고 접근 검증의 책임을 좁히며, 시스템 관리자와 채널 단위 권한을 구분하는 설계.
테스트 편의 때문에 운영 코드의 의미를 바꾸지 마라
운영 행위가 더 명확해지거나 레거시에 테스트 경계가 필요할 때만 코드를 바꾸고, 테스트만 쓰는 값과 메서드를 억지로 노출하지 않는 기준입니다.
첫 테스트는 서툴러도 된다, 나중에 리팩터링하라
지키고 싶은 행위를 검증하는 테스트부터 만들고, 실행에 필요한 만큼 목을 쓰며, 반복과 리뷰를 통해 테스트 설계를 개선하는 방법입니다.
실제 트래픽 모양에서 성능 테스트를 설계하라
부하 도구를 고르기 전에 트래픽 규모와 유입 모양을 추정하고, 여유를 정하며, 실제 위험이 있는 기능에만 검증 근거를 요구하는 방법입니다.
공유 테스트 DB 없이 신뢰할 수 있는 데이터베이스 테스트 만들기
잡아야 할 실패에 따라 목, 인메모리 DB, Testcontainers, 실제 DB를 고르고 일반 테스트는 공유 인프라에서 격리합니다.
만든 개발자가 떠나도 살아남는 소프트웨어
좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.
단위 테스트는 비즈니스 의도를 지켜야 한다
비즈니스 레이어 단위 테스트는 설계를 돕고, 중요한 동작을 기록하며, 다음 개발자가 위험한 변경 앞에서 한 번 더 생각하게 할 때 의미가 있습니다.
리더와 라이터 컴포넌트로 비즈니스 흐름 드러내기
리더와 라이터는 저장소 세부사항과 변경 범위를 감추고 비즈니스 계층에 정책을 남깁니다. 다만 서비스 수명이 그 비용을 정당화해야 합니다.
거대한 서비스 클래스를 책임과 계층으로 분리하는 법
생성자 의존성과 import로 비대해진 서비스를 진단하고, 새로운 아키텍처 이름을 붙이기 전에 응집된 책임부터 분리합니다.