pile·
백엔드·LINE Engineeringline·

코드 품질 개선 기법 27편: 티끌이 모여 태산이 되듯 의존성도 쌓이면

문제`LatestNewsSnippetUseCase` 같이 작은 유스케이스도 리포지터리·포매터·팩토리 등 의존성을 하나씩 추가하다 보면 6~7개가 쌓여 테스트·재사용·이해 비용이 누적된다.

접근의존성을 누적하기 전에 "이 클래스의 책임 단위에 정말 필요한가" 를 물어 분리하거나 합친다. 포매터·팩토리 같은 보조 의존성은 호출자로 끌어올리고 유스케이스는 도메인 변환만 담당하도록.

결과작은 클래스가 점점 무거워지는 경향을 "의존성도 쌓이면 태산" 으로 표현. 코드 리뷰에서 의존성 개수를 의도적으로 점검하도록 유도한다.

LINE Engineering
LINE Engineering 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  2. 백엔드·네이버페이네이버페이·

    Composite PK에서 시작된 Spring Boot 4 / Spring Batch 6 업그레이드 기록

    문제Spring Data JDBC 의 Composite ID 적용을 위해 Spring Boot 3.5 → 4.0.1 업그레이드 시 Spring Batch, Kotlin, Jackson 등 전체 스택 메이저 전환 필요.

    접근Spring Boot 4 / Spring Batch 6 / Spring Framework 7 / Kotlin 2.3 / Jackson 3 / Kotest 6 / Gradle 9 / ojdbc11 순차 업그레이드. Composite ID 는 Persistable 인터페이스로 구현, JdbcDefaultBatchConfiguration 상속으로 메타데이터 저장.

    결과기술 부채 해결 + 장기 유지보수성 개선. 운영 DB 접근 정책 충돌을 사전 식별해 안정적 배포 달성.

    #kotlin#spring#spring-boot+3