- NextStep & 우아한 형제들 주관
- 일반 사용자용 서비스를 개발할 때 필요한 역량 습득
- 리뷰어의 코드 리뷰를 통해 책임 주도 설계를 기반으로 유연한 구조의 클린 코드를 작성
ATDD(인수테스트 주도 개발), TDD(테스트 주도 개발)를 함께 적용하여 테스트 코드를 기반으로 구현
- OutSide-In, InSide-Out 방식
- OutSide-In : top-down 방식, 외부 인터페이스부터 내부 방향으로 진행
- InSide-Out : bottom-up 방식, 내부 코어부터 외부 방향으로 진행
- 상태 검증과 행위 검증 차이
- 상태 검증 : 결과(상태) 값을 확인하여 판단
- 행위 검증 : 해당 행위(메서드 등)가 실행되었는지를 확인하여 판단
- 실제 객체가 아닌 테스트 목적으로 사용되는 가짜 객체 Test-Double(Mock, Stub 등)
- Mock : 예상되는 호출 명세, 올바르게 수행됐는지 검증
- Stub : 호출 시 미리 정의한 값을 반환 (일반적으로 Mock으로 잘못 알고 있는 객체)
주요 피드백 내용
- 상황에 따라 RuntimeException 보다는 구체적인 예외를 던지는 것이 좋음
- 예외 메시지에 대한 규정도 필요함
- 자바에서 final 키워드는 불변 객체를 의미하지 않지 인스턴스 재할당을 막을 수 있음
- 객체 지향 설계를 위해 거리값(distance)을 원시 타입이 아닌 객체로 표현하는 것이 효과적
- 유효성 검사를 객체 내에서 처리하면 책임이 분리되어 안전하고 유연한 구조가 됨
주요 피드백 내용
- 객체 간 의존성(결합도)을 최대한 낮출 것 (통제가 불가능한 외부 라이브러리 등)
PathFinder
->Line
->Section
흐름으로 라이브러리 의존성이 전달되어 사이드 이펙트가 발생할 확률이 높음
- 특정 객체를 파라미터로 전달할 때 불필요한 부분까지 넘기는지 확인 필요
- 불필요한 부분까지 의존하는 것과 다름이 없어서 필요한 부분만 전달하는 것이 좋음
- 또한 특별한 이유가 없으면 객체 직접 참조 회피를 위하여 객체를 직접 넘기는 것을 지양할 것
Collections.unmodifiableList(stations);
같이 불변 형태, 원시 타입 등으로 제공하는 것이 효과적
- 그 외 부가적인 객체 그래프 탐색이 불필요하게 발생할 수 있음
주요 피드백 내용
- 엔티티에서 객체를 통해 직접 연관 관계를 맺지 않고
Id
를 의존함으로써 다른Aggregate
에서 데이터 변경을 막아줄 수 있음 - 데이터 유효성 검사가 필요한 경우
Entity
에서 더티체킹 등의 방법으로 처리하는 것이 객체 지향에 가까울 수 있음- 하지만 상황에 따라
Repository
를 사용해 직접 데이터를 처리하는 것이 깔끔할 수도 있음
- 하지만 상황에 따라
- 컨트롤러에서
Response
에 반환 값을 담지 않을 때Void
를 명시 해주는 것이 좋음ResponseEntity<MemberResponse>
->ResponseEntity<Void>
- 요금 할인 정책을 담당하는
Enum
의 이름이Passenger
인 것은 직관적이지 못함Passenger
->FarePolicyByPassenger
변경
- 상황에 따라 데이터 유효성 검사 위치를 잘 선택할 것(생성자, 팩터리 메서드 등)
- 내부에 인스턴스 변수가 추가되는 경우 생성자를 수정하는 것보다 메서드를 제공하는 것이 유연한 설계가 될 수 있음
ATDD 강의 실습을 위한 지하철 노선도 애플리케이션
cd frontend
npm install
frontend
디렉토리에서 수행해야 합니다.
npm run dev
./gradlew bootRun
버그를 발견한다면, Issues 에 등록해주세요 :)
This project is MIT licensed.