우아한 테크 캠프 4기 도전기

지속가능한 소프트 웨어를 향해

1차 미션 과제

• 도메인 로직에 단위 테스트를 구현하기 ( product 코드 이전에 테스트 케이스 부터 작성하기)
• indent 1까지만 허용 ( 달성시 까지 리팩토링 하기 )
• 8에 추가된 stream api를 사용하지 않고 구현
• else 예약어를 쓰지 않기 ( switch/case도 허용 x)
• 함수(또는 메소드)의 길이가 10라인을 넘어가지 않도록 구현.
• 도메인과 컨트롤 뷰 분리하기

느낀점

• 테스트 케이스를 우선 작성하고 product 코드를 작성하니 빠른 작성이 가능했다 (분할 정복 가능)
• 하지만 테스트 주도 방식이 프로그램 작성의 끝은 아니다.
• 객체 지향적 설계와 사상을 동시에 담아내기 위해 다른 노력이 필다.
• 관계 설정 설계는 다른 문제이다.

남은 기간 공부해 볼 문제

• MVC 모델 직접 구현해 보기 ( 스프링 사용하지 않고)

2차 미션 과제

• 기본 1차 미션 과제
• 일급 콜렉션 구현
• 문자열과 원시값을 포장해서 사용
• 메소드 분리를 넘어 클래스 분리

느낀점

• 테스트 케이스로 문제 쪼개기 => 분할정복
  • 머리속 생각은 의외로 모호하다. 오히려 계속 작은 단위로 테스트 케이스를 직접 코드를 짜보는게 좋다.
  • 의외로 테스트 케이스를 짜면서도 겹치는 경우가 많다. => 테스트 케이스를 작성하면서 리팩토링이 된다.
• Over Engineering 확장 가능한 프로그램의 경계는
• 일급 콜렉션 -> 의외로 하나의 클래스에 하나의 멤버변수를 만드는게 쉽지않다.
  • 계속 추가된다. -> 또 메소드 클래스 분리!!
• 애초 클래스 설계와 달라지는 경우도 생긴다.
• 패키지가 (또는 클래스가) 깊어짐에 따라 예외처리의 문제 발생(고민)
  • 가령 RacingGame 은 RaceTrack을 참조하고 RaceTrack 은 Car를 참조하고 Car 는 CarName을 참조하는데 CarName에서 Validate를 하는 기능이 있고 여기서 예외를 발생시킨다면, 이는 프로세스를 담당하는 RacingGame 까지 예외를 전달해야 하는 상황. 메소드의 호출 순서가 보장되어야 할 때는 문제를 어떻게 해결해야 할까?
  • 순서
• 아직 익숙하지 않아 시간이 많이 걸림

짧은 시간이지만 목표를 가지고 의식적으로 연습하며 조금 더 튼튼한 설계, 조금 더 유연한 방법들을 찾으며 고민하는 시간이 힘들지만 즐거운 시간이었다. 아직 부족한 부분이 많기에 기회가 된다면 꼭 우아한 태크 캠프를 통해 이러한 부분들을 채워나가고, 또 훈련하고 싶습다!!

남은 기간 공부해 볼 문제

• 클래스가 작은 단위로 나뉘다 보면 메소드 호출 순서가 보장되어야 하고

---