스택큐힙리스트

“친구 추천 코드를 뜯어보니 추천·랭킹·알림·로깅까지 한 클래스에 다 들어 있었다.”SNS 서비스에서 친구 추천은 트래픽을 좌우하는 핵심 기능입니다. 그런데 출시 1년 만에 버그가 폭발하고 배포가 두려워진 팀이 있었습니다. 원인은 단 하나, SRP(단일 책임 원칙) 위반이었습니다. SRP란 “클래스가 변경돼야 할 이유는 하나여야 한다”는 원칙이죠 이번 글에서는 실제로 벌어졌던 ‘친구 추천 서비스’의 SRP 위반 패턴을 해부하고, 단계별 분리 전략을 살펴봅니다.1. 실패의 전조 – 거대 FriendRecommendationService초기 구현은 다음과 같았습니다.데이터 수집: 사용자 그래프·활동 로그·팔로잉 기록 한꺼번에 조회후보 생성 + 랭킹: 협업 필터링 점수 계산 후 랭킹 적용알림 전송: 푸시·이메..

“클래스가 바뀌어야 할 이유는 단 하나여야 한다.” 이 단순한 문장이 지켜지지 않을 때 나타나는 것이 바로 거대 클래스, if‒else 난무, UnsupportedOperationException 남발 같은 대표적인 코드 냄새입니다. 국내 개발자들이 많이 찾은 SRP(단일 책임 원칙) 리팩터링 후기들을 종합해, 실무에서 바로 써먹을 7단계 체크리스트를 정리했습니다. 1. 코드 냄새 스캐닝new 나 if(type)가 몰려 있는 거대 메서드한 클래스에 DB + 네트워크 + 뷰 로직이 섞여 있는 경우인터페이스 구현체가 사용하지 않는 메서드에 예외를 던질 때2. 책임 라벨링클래스·메서드마다 “이 로직은 누구를 위해 존재하나?” 메모를 붙여보세요.라벨이 두 개 이상이면 SRP 위반 후보입니다.3. 행위·데이터 분..

“고수준 모듈이 저수준 모듈에 끌려다니지 않게 해라.”― 의존 역전 원칙(Dependency Inversion Principle)SOLID의 마지막 퍼즐, DIP는 “설계 방향을 아래에서 위로 뒤집는” 순간 코드를 한층 유연하게 만듭니다. 국내 인기 블로그에서도 스프링·안드로이드 예제로 꾸준히 조회 수를 올리는 이유가 바로 여기에 있죠.1. DIP란 무엇인가?정의:고수준 모듈(비즈니스 규칙)은 저수준 모듈(구현 세부)과 직접 의존하지 않는다.양쪽 모두 추상화(인터페이스·추상 클래스) 에 의존해야 한다.추상화는 구체화에 의존해서는 안 된다.한마디 요약: “구체가 아니라 계약에 기대라.”2. DIP가 깨질 때 벌어지는 일비즈니스 로직 락인: 구현 세부 변경이 배포 리스크로 직격탄.테스트 지옥: 실 컨크리트 ..

“클라이언트는 자신이 사용하지 않는 메서드에 의존해선 안 된다.”― 로버트 C. 마틴SOLID 다섯 형제 중 네 번째, ISP(Interface Segregation Principle) 는 “세분화된 인터페이스”로 코드 의존도를 슬림하게 만드는 비법입니다.1. ISP가 왜 필요할까?쓸데없는 구현 강요 OUT거대한 인터페이스는 “안 쓰는 메서드”까지 구현하게 만들고, 결국 버그와 의존성 폭탄을 낳습니다. 변경 범위 최소화잘게 나뉜 인터페이스는 새로운 기능이 추가돼도 영향 범위가 좁아 회귀 위험이 적습니다.테스트·모킹이 쉬워진다필요한 기능만 담긴 인터페이스를 모킹하면 단위 테스트가 간단해집니다.2. ISP가 깨질 때 나타나는 신호‘God Interface’: 메서드 수십 개짜리 인터페이스를 구현하느라 빈 몸..