개요 Red-Green-Refactor는 TDD의 단위 작업 루프다. 세 단계가 각각 다른 목적을 가지며, 한 번에 한 가지만 한다는 원칙이 전부다. Red 단계에서는 설계를 생각하고, Green 단계에서는 통과만 생각하고, Refactor 단계에서는 정리만 생각한다. 단계 질문 금지 사항 Red 이 코드를 어떻게 쓰고 싶은가 구현 코드를 건드리는 것 Green 어떻게 하면 가장 빨리 통과하는가 일반화, 미리 하는 설계 Refactor 무엇이 중복인가 동작 변경, 기능 추가 Robert C. Martin은 같은 루프를 세 가지 금지 규칙으로 다시 썼다. 사이클을 초 단위까지 조인 형태다. ...
정의 Self-testing Code는 명령 하나로 테스트 전체를 실행할 수 있고, 그 테스트가 통과하면 코드에 중대한 결함이 없다고 확신할 수 있는 상태를 가리킨다. Martin Fowler가 Refactoring에서 이 실천에 붙인 이름이다. Fowler가 제시하는 사고 모형은 명확하다. 소프트웨어 시스템을 만드는 동시에 그 시스템 내부의 결함을 감지하는 버그 탐지기를 함께 만든다. 팀의 누군가가 실수로 버그를 넣으면 탐지기가 울린다. 스위트를 하루에도 여러 번 돌리면 버그가 들어온 직후에 감지되므로 최근 변경분만 살펴보면 되고, 그만큼 찾기가 쉬워진다. ...
정의 Anemic Domain Model(빈혈 도메인 모델)은 도메인 객체에 getter와 setter만 있고 행위는 거의 없으며, 모든 도메인 로직이 Service 객체에 있는 설계다. Martin Fowler가 2003년에 안티패턴으로 지목했고, Eric Evans도 같은 진단에 동의했다. Fowler는 이것을 “꽤 오래 존재해 온 안티패턴"이라고 부르면서, 제대로 된 Domain Model의 지지자로서 이것이 유행하는 것은 좋은 일이 아니라고 못 박는다. 증상 Fowler의 서술이 정확하다. 빈혈 도메인 모델의 기본 증상은 처음 보면 진짜처럼 보인다는 것이다. 도메인 공간의 명사를 따라 이름 붙은 객체들이 있고, 이 객체들은 진짜 도메인 모델이 가진 풍부한 관계와 구조로 연결되어 있다. ...
들어가며 현재 서비스중인 AuthService가 387줄의 거대한 God Object로 성장해버렸다. 로그인, 회원가입, 소셜 로그인, 이메일 찾기, 비밀번호 변경 등 인증 관련 모든 기능을 한 클래스에서 처리하다 보니 테스트도 어렵고 수정할 때마다 긴 코드를 찾아봐야 하다보니 유지보수에 있어서 너무 불편했다. 이를 SRP 원칙에 따라 3개 서비스로 분리하고, Facade 패턴으로 재구성한 과정을 기록했다. 문제 상황 God Object가 된 AuthService AuthService - 387줄 - 의존성: 11개 - 담당 책임: 6가지 1. 로그인/로그아웃 (토큰 관리) 2. 회원가입 (검증 + 외부 API + DB 저장) 3. 소셜 로그인 (카카오/구글/네이버) 4. 이메일/전화번호 찾기 5. 이메일 인증 발송/확인 6. 비밀번호 변경 한 클래스가 6가지 책임을 가지고 있고 명백한 SRP 위반이다. ...
들어가며 현재 사내에서 서비스중인 앱의 백엔드 코드에서 중복되는 코드가 심하게 일어나는 부분이 있었다. 회원과 관련된 추가정보(경력, 학력, 논문 등)들이 총 7개가 있는데 이 7개의 도메인들의 CRUD 로직이 100% 동일하다는 것에 템플릿 메서드 패턴을 적용하여 리팩토링을 해보면 어떨까 생각이 들었다. 추가정보 도메인 총 7개의 기존 서비스 로직의 코드 라인에는 생성, 조회, 리스트조회, 수정, 일괄 수정, 삭제, 일괄 삭제, 소프트 삭제, 삭제복원을 포함하여 약 210줄의 코드가 동일한 로직으로 중복되고 있었다. 문제 상황 분석 중복 코드의 심각성 7개의 서비스 클래스가 거의 동일한 구조를 가지고 있었다. 예를 들어 경력(Career) 서비스와 학력(Education) 서비스를 비교해보면 다음과 같았다. ...