스택큐힙리스트

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

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

“클래스가 바뀌어야 할 이유는 단 하나뿐이어야 한다.”이 한 줄이 바로 단일 책임 원칙(SRP, Single Responsibility Principle)의 핵심입니다. SOLID 다섯 가지 중 첫 타자로 꼽히는 SRP는 ‘거대한 설계론’이 아니라 내일 당장 리팩터링 PR에서 팀원을 설득하기 위한 실전 기준이죠. 오늘은 SRP 개념부터 적용 팁까지 한눈에 정리해 봅니다.1. SRP란 무엇인가?정의: “모듈·클래스·함수는 하나의 책임만 가져야 한다.” 책임이란 변경 이유와 동치입니다. 코드가 수정되는 트리거가 하나만 존재해야 유지보수성이 폭발적으로 올라갑니다.왜 중요한가?변경 범위 최소화 → 버그 격리테스트 단순화 → 빠른 CI재사용성 상승 → 생산성 향상“잘게 쪼갠 클래스가 오히려 읽기 쉽다”는 개발 블..