[NEXTSTEP] ATDD 과정 4주차 피드백, 5주차 시작[끝]

 

 

2023.07.29 - [공부 기록] - [NEXTSTEP] ATDD 과정 3주차 피드백, 4주차 시작

[NEXTSTEP] ATDD 과정 3주차 피드백, 4주차 시작

 

3, 4주차 다시 보기

• Favorite과 Member, Favorite과 Station
  • Favorite과 관련 있는 객체
    • Member
    • Station
  • 모든 의존성을 객체 참조로 구현하면?
    • 객체간 결합도가 높아짐
    • 다른 객체로 탐색이 가능해짐
    • DB에서 조회하거나 ORM 사용시 복잡도 증가
  • 객체 참조를 피하는 방법
    • 간접 참조 (Repository를 통한 탐색)
    • 모든 의존성을 간접 참조로 구현하면?
      • 객체간 결합도가 낮아짐
      • DB에서 조회하기 위해 서비스 레이어 로직 복잡도 증가
  • 어떤 상황에 객체 잠조를 할까?
    • 함께 생성되고 함께 삭제되는 객체들을 묶어라
    • 도메인 제약사항(비즈니스 로직)을 공유하는 객체들을 묶어라
    • 가능하면 분리하라

4주차 다시 보기

• UserDetails가 null이면?
  • LoginMember - @AuthenticationPrincipal UserDetails userDetails
  • 할인 정책 때문에 경로 조회시 UserDetails가 필요해짐
    1. @AuthenticationPrincipal(required = false) UserDetails userDetails로 두어서 nullable 처리
    2. 익명 사용자 객체(extends UserDetails) 를 만들어서 UserDetails이 null이면 반환하도록
    3. Null Object Pattern
• 요금 정책 설계
  • 요구사항
    • 요금 계산 기능 구현
      • 거리 기준 요금 정책
  • 단위 테스트
    • 거리 기준 요금 정책 단위 테스트 작성
    • 경계값 검증을 중점적으로 수행
      • 미만, 초과
    • 요금 계산 추가 가이드
      • 10~ 50km : 900
      • 50km > 100원
      • 첫번째 계산이 맞음.

• 요금 계산 기능 구현
  • 거리 기준 요금 정책
  • 노선 추가 요금 정책 +
  • 요금 할인 정책 +

 

• Chain of Responsibility (책임 연쇄 패턴)
  • 서블릿 필터, 인터셉터 등에서 활용 됨

• 문서화 테스트
  • 스텝 메서드
    • 인수 조건 확인을 위한 각 조건과 단계를 메서드로 분리해서 재활용
    • ReqeustSpecification given을 넘겨 받아 처리하면 문서화 테스트에서도 재사용이 가능하여 중복 제거 가능
• Spring Rest Docs 팁 

• 기본적으로 6개의 스니펫이 생성 됨
  • Snippet Template 재정의
    • request-fileds 기본 템플릿은 패스, 타입, 설명 세가지
    • 기본 template 파일을 찾아 기본 골조를 가져와 src/test/resoureces/org/springframework/restdocs/templates/asciidoctor/ 위치에 커스텀하여 추가 가능
    • .attribute(key(”optional”).value(”false”))
    • 필드 메서드 분리
    • anchor를 추가하여 문서 수준에서의 중복 제거 가능

 

• • bootJar task 재정의
    • 배포 후 문서 접근을 위해 static 디렉토리를 옮겨야 함
    • task 재정의를 통해 문서를 static/docs로 옮기도록 설정
    • 로컬에서 확인하고 싶을 때 별도의 task를 만들어서 문서를 확인 할 수 있음
    • 문서화 테스트만 수행하고 싶을 때 패키지를 분리하여 filter를 통해 documentation 테스트만 수행하도록 설정 할 수 있음

ATDD 적용 과정 및 사례

• 사람은 기본적으로 변화를 거부하는 성향
• 팀은 변화를 거부하는 성향이 더 강함
• 대부분의 사람들은 변화에 실패한 경험을 가지고 있음
  • 나 혼자 시작하기
  • 내가 맡은 기능 구현에 TDD, 리팩터링 적용
  • 묵묵히 혼자 진행
  • 관심 있는 사람이 생기면 전파
• 리더가 하지 말라고 하면
  • 그만둔다
  • 나는 많이 성장했기 때문에 절대 손해 보는 장사가 아니다. (ㅋㅋ)
• 나혼자 ATDD
  • 토이 프로젝트로 경험 쌓기
  • 간단한 기능부터 적용해보기
  • 경험해보면서 상황에 맞는 방법 찾기
• 다함께 ATDD( in 개발팀)
  • ATDD 개발 프로세스 룰 정하기 (인수조건, 포맷 등)
  • 팀 회의와 회고를 통한 피드백
  • 살아있는 규칙 정하기
• 기획 & QA와 함께하는 ATDD
  • 기획, QA 설득하기(장점 소개)
  • 다같이 만드는 요구 사항
  • ATDD 적용 전과 후, 장점과 단점
• 테스트가 없는 레거시 환경
  • 인수 테스트 먼저 작성하기
    • 기존 기능을 검증하는 인수 테스트 먼저 만들기
    • 기존 코드를 변경하는 것이 아니기에 팀의 동의 없이 가능
  • 인수 테스트 작성의 걸림돌
    • 모든 기능에 대해 하려는 마음 버리기
    • 쉬운 기능부터 적용하기
      • 사전 작업이 많이 없는 기능 (Given 구문이 적은 기능)
      • 외부 영향이 없는 기능 (외부 API or 서드 파티 로그인 등)
  • 인수 테스트 보호 속에 단위 테스트
    • 단위 테스트를 작성하다 보면 테스트하기 어려운 코드를 만나게 됨
    • 이 때 리팩터링을 함께 진행해야하는데 이 때 인수 테스트로 기존 기능이 영 향을 받지 않는지 확인하면서 진행
  • 성공적인 ATDD 적용을 위해
    • 아주 쉽게 시작할 수 있는 부분부터 도입
    • 조금씩 상황에 맞게 조정
    • 가벼운 프로세스부터 시작, 문제점 발견 시 민첩하게 대응
• 함께하는 ATDD
  • 왜 좋은지 설득하기
    • 개발 친화적인 용어는 제외하고 설명하기
    • 기존 방식과 비교하여 장점 이야기하기
  • 함께 만드는 인수 조건 - Discuss 회의
    • 기획/개발/QA 함께 인수 조건 회의 참여
    • 화면 기반으로 작성할 경우 이해도가 높음
    • 모든 인수 조건을 다같이 만드는건 비효율적
  • ATDD 적용 전과 후, 장점과 단점
  • Common Understaning
    • 다른 포지션의 관점은 물론 업무 프로세스도 간접적으로 익힐 수 있음
    • 다른 포지션의 진행 상황에 대한 인지와 이해도가 높아짐
  • 인수 조건 정의의 어려움
    • 문서를 어떻게 관리해야 할 지에 대한 고민이 필요
  • 리소스
    • (기획/개발) 두번 작업하는 느낌을 받음

728x90

자주 듣는 질문

• 인수 조건은 어떻게 도출하나요?
• 어떤 기준으로 인수 테스트를 작성하면 좋나요?
• 답변 : 팀원 모두의 공통의 이해를 통해 작성되기 때문에 작성 전에 사용자 스토리든 기능이든 요구사항이 있기 마련이다. 스토리부터 작성해가보자.

스토리 맵핑과 함께하는 ATDD

• 어떤 기능들이 먼저 배포 되어야 하는지 우선순위를 정할때 도움이 된다.
• 스토리 맵핑 워크샵
  1. 작업 나열하기
     1. 주제 : 오늘 아침에 일어난 일
        1. 오늘 아침 일어나서 가장 먼저 무엇을 했는지 생각
        2. 그 다음 무엇을 했는지 포스트잇에 적고 붙인다.
        3. 반복
        4. 회사에 들어오기 전까지 했던 일을 적는다.
  2. 활동(Activity) 구성하기
     1. 함께 움직여야 하는 작업 묶음 발견
     2. 큰 목표를 달성하기 위해 함께 움직여야 하는 것으로 보인다면 묶음
     3. 각각의 Task가 어떤 목적을 갖는지 보여서 세부적인 단위를 조정하기 쉬워 짐
  3. 스토리 나열하기
     1. 작업(Task)별로 스토리 형태로 작성하기
        1. 욕실에서 해야하는 일들
        2. 아침을 만들기 위해 주방에서 해야하는 일들
     2. 작업별 세부 사항 및 대안 스토리 고려하기
        1. 따뜻한 물이 나오지 않는다면?
        2. 우유나 시리얼이 다 떨어졌다면?
        3. 세부사항, 대안, 변화 그리고 예외를 스토리맵 본체에 추가
  4. 우선순위에 따라 그룹 나누기
     1. 우선순위 기준으로 그룹 나누기
     2. MVP(성과 기준)를 가장 상단으로 나누기
     3. 다음 우선순위 기준으로 나누기
     4. 그룹에 따라 배포 라인을 만들 수 있음

인수 조건 도출

• 스토리 맵을 통해 구성한 스토리로 시나리오를 생성
• 시나리오를 기반으로 인수조건 작성

 

마지막 미션 하나를 남겨두고 회사에서 핵심 도메인 리팩토링 및 배포를 진행하는 바람에 끝내지 못했다.

그리고 곧 유스콘 발표가 예정되어 있어서 그 내용이 끝나야 마지막 미션을 할 수 있지 않을까 싶다.

 

솔직히 핑계이긴 하다. 이 글 적을 시간에 해도 되고 피곤하다고 누워있을 시간 10분씩만 썼어도 했겠지..

 

과정을 마무리하며 다시금 되새긴다.

 

과정을 슬기롭게 임하는 방법 - 주변 환경을 정리해 꾸준히 연습할 시간 확보

• 환경 바꾸기
  • TV를 보지 않는다
  • 스마트폰을 보는 시간을 줄인다.
• 시간을 확보하기
  • 퇴근 후 카페로 출근한다
  • 야근을 하지 않는다
• 여러분의 의지력을 믿지 마세요. 환경을 바꾸세요.

매일 1~2시간씩 미션 진행하기

• 한번에 모두 구현하기 보다 매일 일정한 시간 투자하는 것이 정말 중요함
• 일주일에 최소 4회 이상 코드리뷰 요청을 보내 코드 리뷰 받기
• 최소 하루에 2시간 이상 투자해야 미션을 완료할 수 있었음

리뷰어 피드백이 상반되는 경우

• 상반되는 의견에 혼란스러워하지 말고 즐기기
• 상반되는 의견에 대해 생각할 수 있는 계기로 생각하기
• 마음껏 생각하고 자신만의 프로그래밍 색깔을 만들기
• 앞선 피드백과 다음 피드백이 상반 될 경우에는 바로 받아들이기 보다는 리뷰어에게 DM을 보내 경험과 의견을 공유하며 피드백을 추가로 얻고 생각의 확장을 하자

지우고 다시 해보기

• 미션의 목적은 기능 구현이 아니라 TDD Cycle 실습 및 경험
• 같은 기능이라 하더라도 두번째 구현할 때는 다른 Cycle을 경험 할 수 있음
• 도메인과 기능에 대한 이해도에 따라 달라지기 때문

정답을 찾기 위해 집착하지 말자

• 미션을 진행하는데 정답은 없다
• 정답을 찾으려는 노력이 오히려 학습을 방해한다
• 현재 상황에서 최선의 답을 끊임없이 찾으려고 노력한다

강의에서 배운 그대로 하지 마세요

• 강의를 통해 여러분의 지평을 넓혔으면 넓힌 그 영역은 질문으로 채우기
• 강의를 듣고 질문이 생겨서 그 질문의 답을 유추해 가는 과정이 필요

 

 

P.S.

5주 동안 정리한 내용은 아래에서 복제 가능

https://www.notion.so/NEXTSTEP-ATDD-d090a6795e1c4d3383fda12b9c3c02b6