Clean Agile - Chapter 5

클린 애자일

위의 책 내용을 참고하여 정리한 글입니다.

자세한 내용은 책에서 확인하세요.

 

애자일 하다는 것은 애자일에 포함된 기술 실천 방법을 도입하는 것이다.

TDD, 리팩터링, 단순한 설계, 짝 프로그래밍 등의 기술 도입이 없다면 애자일이 아니다

테스트 주도 개발

TDD의 세 가지 규칙

1. 코드를 먼저 작성하면 안 된다.

2. 실패를 위한 테스트 코드를 만들려 하면 안 된다.

3. 테스트 통과를 위해 필요한 것 외에 더 많은 코드를 작성하면 안 된다.

장점

1. 디버깅이 거의 필요 없다.

 

위의 규칙을 다 지키는 이상적인 TDD는 초, 분 단위로 테스트가 동작하며

굳이 디버깅을 하지 않아도 직전에 작성한 코드에 문제가 있다는 걸 알 수 있다.

 

이상적인 경우이지 디버깅이 필요 없는 것은 아니다.

( UI 쪽 버그나 sdk 자체의 문제라면 디버깅은 당연히 필요하다. )

 

2. 전체 시스템의 코드 예제

 

완벽하게 작성된 테스트는 그 자체로도 코드 예제이다.

 

어떤 객체와 함수가 있는지, 어떻게 사용하는지, 무엇을 반환하는지, 언제 예외가 발생하는지

모든 걸 한눈에 확인할 수 있다.

 

3. 결정에 힘을 준다.

 

테스트가 고려되지 않고 만들어진 코드들은

추후에 테스트를 위해 결합도, 클래스를 분리 등 코드 구조를 변경하여야 한다.

 

이러한 진행은 일정에 압박이 왔을 때 테스트 작성을 다음으로 미루는

넘어가기 쉬운 핑계가 되고 테스트에 구멍을 만든다.

 

이러한 구멍들은 테스트가 모두 통과되어도

코드가 배포 가능한 상태라는 결정에 어떠한 힘을 주지 못한다.

 

TDD를 통해 프로젝트를 진행할 경우

테스트의 통과는 코드가 배포 가능한 상태라는 것을 결정할 수 있는 힘을 실어준다.

( 커버리지 100% 가 아니어도 된다. 가능하긴 할까? )

 

4. 결합도가 낮아진다.

 

테스트를 작성한 후 개발을 진행하면 설계를 테스트하기 쉽게 만들고,

자연스럽게 결합도가 낮은 설계가 만들어진다.

리팩터링

Refactoring is a disciplined design skill to improve the structure of code without changing its external behavior. And
refactoring is part of the TDD cycle.

Agile TDD and Refactoring - Craig Larman

리팩터링은 테스트는 통과하면서 동작은 그대로 두며 이름이나 구조가 변경되는 작업으로

TDD 사이클의 일부이다.

 

리팩터링의 순서는 다음과 같다.

 

1. 테스트를 작성한다.

2. 테스트를 통과하게 한다. => 여기까지는 TDD이다.

3. 코드를 정리한다.

4. 1번 반복

실천 방법

리팩터링은 계획을 가진 활동이 아니며 일정에 나타나서는 안 된다.

TDD 사이클의 일부로 개발을 진행하면서 코드를 깔끔하게 변경하는 정도로 진행해야 한다.

 

아무리 큰 사이즈의 리팩터링이라도 시간을 잡지 않고

업무의 중간중간에 기능 변경과 함께 리팩터링을 진행해야 한다.

 

절대 설계 변경이 목적인 프로젝트는 만들면 안 된다.

 

책의 앞부분에서도 리팩터링에 대해 비즈니스 가치가 없으니 스토리를 할당하면 안 된다는

내용이 나오고, 위의 실천방법을 따라서도 스프린트 주기에는 리팩터링만을 위한 시간을 할당할 수 없다.

 

굉장히 이상적인 경우라 생각하고 넘어가기로 했다.

그렇지 않다면 영원히 변경이 없는 화면의 코드는 영원히 java 일 것이다.

단순한 설계

켄트 벡이 세운 단순한 설계의 규칙

 

1. 모든 테스트 통과할 것

=> 당연

 

2. 의도를 명확하게 드러낼 것

=> 리스크 개수를 반환하는 함수가 getInt() 라면 안된다.

 

3. 중복을 없앨 것

=> 같은 기능의 함수가 여러 곳에 있으면 안 된다. 하나의 클래스나 함수로 작성해야 한다.

 

4. 구성 요소를 줄일 것

=> 클래스, 함수, 변수 같은 구성 요소의 수를 줄이려 노력해야 한다.

=> 3번의 파생이라 생각한다. 중복을 없애기 위해 만든 클래스들이 너무 많으면 안된다.

ex) getCurrentDay(), getCurrentMonth() 함수가 각각 DayUtils, MonthUtils로 나뉘면 안 된다.

짝 프로그래밍

필수는 아니다.

강요해서도 안된다.

잠깐씩 하는 것이다.

수치는 중요하지 않지만 업무 비중의 50% 정도가 좋다. ( 잠깐씩 하라면서... )

한 번에 15~30분 정도가 도움이 된다.

 

세명 이상이 모이는 짝 프로그래밍을 몹(Mob) 프로그래밍이라 한다.\

이득

짝 프로그래밍은 개발 비용의 증가한다.

 

대신, 자연스럽게 팀원 전체가 공통된 지식을 공유할 수 있고,

팀에 핵심인력이 생기지 않도록 예방할 수 있다.

방법

한 명이 짜고 그걸 지켜봐도 되고,

한 명은 테스트 한명은 구현과 같은 방식으로 진행해도 된다.

 

아무런 역할이 없어도 된다.