[과제]

시연 영상을 보고 TripService Kata를 수행한 후 소스 코드와 퀴즈 답변 제출

  • 목표
    • 앞으로 배울 내용을 사전에 체험
    • 관련 주제
      • 코드 스멜, 클린 코드, 리팩토링, 단위테스트, TDD
      • 레거시 코드를 안전하게 리팩토링 하는 방법
      • 레거시 코드에 테스트를 작성하기 위한 기법
      • 객체지향 도메인 개발
  • 사전 과제

  • 상세

    • Kata 시연 영상을 보고 TripService Kata 수행 (Java로 수행)
    • 퀴즈 답변 작성

  • 평가 기준

    • 제출 여부 (~5.24)

  • 제출 내용

    • Kata 결과 코드가 담긴 git Repository 제출 (커밋 이력 포함)
    • 퀴즈 답변
      • 과정 운영자에게 이 메일로 제출

Git Repository 파일로 추출하기
Repository 디렉토리 전체 압축
Git 디랙토리 Zip 등으로 압축
Git bundle 명령어로 특정 브랜치 추출
git root로 이동
Bundle 생성: git bundle ../{번들이름} {대상브랜치 이름} ex) git bundle ../homework.bundle master

Questions

  1. Original TripService 에서 개선이 필요한 점들을 기술하세요.
    1. friend확인 기능의 코드 위치 (Feature Envy ?): User 클래스로 이동한다. 친구인지 판단하는 기능은 User의 기능이다.
    2. TripDAO클래스에 직접 의존한다.
  2. 레거시 코드에 테스트를 작성할 때에 인덴트가 얕은 부분부터 작성하는 이유는 무엇인가요?
    1. 얕은 인덴트 부터 unit테스트를 작성하면서 점진적으로 대상코드에 대한 이해도를 높일 수 있다.
    2. 반대로 깊은 인덴트 부터 unit테스트를 작성한다면 처음부터 대상 코드를 모두 이해해야 하며 많은 양의 테스트 데이터를 준비해야 한다.
  3. 리팩토링 할 때에 코드의 인덴트가 깊은 부분부터 하는 이유는 무엇인가요?
    1. 중간부터 리팩토링을 하려면 코드를 전부 이해하고 있어야 한다.
    2. 가장 깊은 인덴트는 다른 것에 의존하지 않는다.
      • 레거시 코드는 글로벌 변수가 많고, 의존관계가 복잡하다
      • 깊은 인덴트 부터 리팩토링을 하면 코드가 점점 줄어들게 된다
  4. 레거시 코드에 단위 테스트를 작성하기 어려운 이유는 어떤 것들이 있을까요?
    1. 구조가 복잡하다
    2. 많은 변수를 사용한다.
    3. 의존성이 있다
  5. 단위테스트에서 DAO를 직접 호출하지 않는 이유는 어떤 것들이 있을까요?
    1. 모르겠음
  6. 시연 중에 코드 커버리지 툴은 어떤 용도로 사용되고 있나요?
    1. 전체 대상코드가 테스트되는지 확인하는 용도로 부가적으로 사용되지만 시연자는 실제 코드가 실행되었는지가 중요하다고 한다.
    2. 커버리지를 확인하며 가장 얕은 인덴트의 코드가 샐행되었는지 확인하는 용도로 사용한다.
  7. 시연 중에 변경 범위가 큰 위험한 리팩토링을 한 이유는 무엇일까요? (50:20~57:04)
    1. 디자인이 잘못 설계되었기 때문이다
    2. TripService 는 MVC 중 모델에 속하는 서버단 코드인데 웹 프레임워크인 USER SESSION을 직접 참조한다.
  8. 시연에서 사용된 단위 테스트의 명명 규칙에 대해 기술하세요
    1. 시연에서 단위 테스트 함수의 이름을 명세서 처럼 작성하는데
    2. should action when condition의 형태이다.
    3. 다시말해 기대하는 동작과 상황을 기술한다.
  9. 클린 코드는 “잘 작성된 산문”과 같은 코드라고도 말합니다. 시연에서 잘 작성된 산문과 같은 코드의 사례를 찾아서 기술하세요.
    1. 완성된 코드를 보면 함수명, 변수면 등에서 논리의 흐름을 파악하기 쉽게 만들어 놓았다.

레거시 코드를 작업 할 때 아주 중요한 것은 메소드가 이렇게 큰 원인을 찾는 것이다.

일반적으로 메소드가 하는 일어 너무 많아서이다.

알고리즘을 개선하거나 메소드를 추출하는 것보다 중요한것은 이 동작이 이곳에 위치하는게 맞는지를 판단하는 것이다.

디자인이 잘못된 경우는 어떻게 할 것인가?

  • 디자인이 잘못된 레거시 코드 위에 테스트코드를 작성해 버리면 디자인을 변경하기가 더 어려워진다.
  • 디자인을 변경하게 되면 테스트코드도 변경해야 하기 때문이다.

예제코드에서는 UserSession에 의존하고 있는 문제가 있다.

규칙
테스트 없는 소스 코드는 수정 불가
단, IDE의 리팩토링 기능을 사용하는 것은 가능
직접 타이핑해서 코드 수정하는 것 불가

이클립스 설정 시 참고
EclEmma 플러그인
코드 커버리지 플러그인
업데이트 사이트: http://update.eclemma.org/
참고: http://dsmoon.tistory.com/entry/EclEmma-Java-Code-Coverage-for-Eclipse

Infinitest 플러그인
단위테스트 자동 실행 플러그인
참고: http://fromm0.tistory.com/124
마켓플레이스에서도 설치 가능

이클립스 static import 설정
mockito, hamcrest matcher 등이 자동으로 import 안 되는 경우 참고
http://javacan.tistory.com/310

  • github

https://github.com/sandromancuso/trip-service-kata

  • 시연 영상

https://www.youtube.com/watch?v=_NnElPO5BU0

http://amara.org/en/videos/5qeTm2IuDCAW/info/testing-and-refactoring-legacy-code/

테스트 코드 작성시에는 얕은 부분 부터 작성한다. 깊은부분을 작성하기 위해선 전체적인 이해가 필요하기 때문이다.

인피니 테스트? : 매번 손으로 돌릴필요 없이 자동으로 테스트를 돌려준다.

리팩토링은 가장 깊은 곳에서 부터 시작한다. 깊은 부분은 다른 것에 의존하는 경향이 적기 때문이다.

results matching ""

    No results matching ""