우아한 테크 캠프 PRO 1주차 회고

1주 차 강의 내용 정리

• 객체 지향 설계 & TDD
• Pre mission(숫자야구게임)에 대한 피드백 & 라이브 코딩

TDD 접근 방법

• UI, DB, 외부 라이브러리에 의존하지 않는 도메인 영역을 집중 설계
• 분리 설계된 도메인에 대한 로직을 테스트하는 것에 집중

단위 테스트 구조

TDD 사이클

TDD의 기본적인 Cycle

나의 연습 방법

1. 가능한 상세하게 도메인 설계를 진행 (할 수 있는 만큼)
2. 도메인 별 구현할 기능들 리스트 업
3. 리스트를 바탕으로 테스트코드 작성
4. 테스트 코드 compile 에러 발생하지 않도록 처리
5. 기능 구현
6. 테스트 코드 확인
7. 리팩터링 & 3~6 반복하면서 개발 진행

* 정량적인 리팩터링 방법 *
=> 객체지향 생활체조 원칙 적용

• 규칙 1: 한 메서드에 오직 한 단계의 들여 쓰기(indent)만 한다.
• 규칙 2: else 예약어를 쓰지 않는다.
• 규칙 3: 모든 원시 값과 문자열을 포장한다.
• 규칙 4: 한 줄에 점을 하나만 찍는다.
• 규칙 5: 줄여 쓰지 않는다(축약 금지).
• 규칙 6: 모든 엔티티를 작게 유지한다.
• 규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
• 규칙 8: 일급 컬렉션을 쓴다.
• 규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

 

Pre-mission(숫자야구게임) 리뷰

소스코드는 github.com/louisJu/java-baseball-ex에서 확인할 수 있음.

 

설명 

: 패키지 구조 - domain과 view로 구분

: 일급 컬렉션을 사용 (ball count, strike count, baseball number를 객체로 래핑함)

: else, indent를 많이 신경 씀.

 

느낀 점

• 시작 전 설계에 대한 깊은 고민 없이 개발하다 보니 자주 수정이 발생.
   => (테스트 코드도 수정이 자주 발생, 커밋할 시점 잡기 어려움, 복잡해짐)
• 개발 전 꼼꼼한 설계에 대한 중요성 다시 느낌.
• 기능의 역할 정의에 어려움
   => 입력한 야구 번호 검증하는 로직을 어디서(baseball.class or resultChecker.class) 처리하는 게 맞는지 고민이 많았음 
• 도메인별 명확한 역할 할당, 다른 도메인에서 사용할 땐 메시지를 전달하여 결과만 받아오도록 처리(캡슐화)
  => 참조 depths(dot)를 한 단계로만 처리하도록 함. 
   ex) result.getBall().getBallCount (X) -> result.getBall()

회고 

 : 첫 시간이었고 현재 서비스에서 Node.js를 이용해서 개발하다가 오랜만에 java를 이용해서 개발하니 친정에 돌아온 듯 재미있었다. 잊고 있었던 원칙들이 새록새록 생각나서 즐겁게 고민하면서 코딩했다.

 

참고자료

객체지향 생활체조 원칙