•
기술 실천 방법이야 말로 애자일의 진짜 핵심으로 애자일을 하고 싶다면 배제해서는 안 된다.
테스트 주도 개발
•
테스트 주도 개발을 설명하려면 책 한 권 분량이 필요할 만큼 복잡한 주제다.
•
이 장에서는 기술적 요소를 깊이 설명하기보다는 동기와 도입 이유에 집중해서 간단히 살펴본다.
•
프로그래머는 다양한 기호를 사용해서 거대하고 굉장히 기술적인 문서를 만들어 낸다. 이 문서에 쓰이는 기호는 모두 정확해야 한다.
•
기호 하나만 틀려도 무서운 일이 벌어질 수 있을텐데, 이런 직업이 또 있을까? 바로 회계사다.
•
회계사는 어떻게 모든 기호가 올바른지 확인할까?
복식 부기
•
복식 부기에서는 모든 거래를 장부에 두 번씩 기록하는데, 회계 장부의 대변에 한 번 쓰고 다른 회계 장부의 대응되는 차변에 또 한 번 쓴다.
•
궁극적으로는 장부를 모두 취합하여 재무 상태표라고 부르는 문서 하나로 만드는데, 대변에 기록한 부채와 자본을 모두 더한 값과 차변에 기록한 자산을 모두 더한 값을 서로 비교하여 제대로 썼는지 검증한다. 두 값의 차이는 무조건 0이어야 한다.
•
테스트 주도 개발은 프로그래머의 복식 부기라고 할 수 있다. 구현해야 하는 동작을 두 번씩 입력한다. 한 번은 테스트로, 그리고 한 번은 이 테스트를 통과하게 만드는 제품 코드로 말이다.
TDD의 세 가지 규칙
•
TDD는 세 가지 단순한 규칙으로 설명할 수 있다.
◦
해당 코드가 없어서 실패하는 테스트 코드를 쓰기 전에 제품 코드를 먼저 쓰면 안 된다.
◦
테스트 코드를 쓸 때는 실패하도록 만들기 위해 필요한 것보다 더 많이 쓰면 안 된다. 컴파일 실패도 실패로 간주한다.
◦
실패하는 테스트를 통과시키기 위해 필요한 코드보다 더 많은 제품 코드를 쓰면 안 된다.
문서화
•
TDD의 세 규칙을 따르며 작성한 테스트는 전체 시스템의 코드 예제가 된다.
•
즉, 테스트는 테스트하는 시스템을 설명하는 문서의 한 형태다.
•
그 외의 TDD를 사용했을 때, 얻을 수 있는 장점들을 간략하게 설명해주셨다.
◦
빠른 피드백의 테스트를 통해서 코드 변경에 적극적일 수 있게 용기를 준다던가
◦
TDD만으로 얻어진 커버리지가 낮다고 해서 굳이 모두 채울 필요가 없다던가
리팩터링
•
리팩터링은 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법이다.
빨강/초록/리팩터링
•
본질적으로 리팩터링은 TDD의 세 가지 규칙을 반복함으로써 이루어진다.
1.
먼저, 실패하는 테스트를 만든다.
2.
그리고 이 테스트를 성공하게 만든다.
3.
그리고 코드를 정리한다.
4.
1단계로 돌아간다.
더 큰 리팩터링
•
요구사항이 바뀌는 것이 반복되어 시간이 흐르게 되는 경우, 더 큰 리팩터링이 필요할 수 있다.
•
한 번에 끝내기 위해 기간을 잡아선 안 된다. 조금씩 조금씩 고쳐나가야 한다.
단순한 설계
•
단순한 설계 실천 방법은 리팩토링의 목표 중 하나로 단순한 설계는 최대한 단순하고 작고 표현력이 뛰어난 구조를 바탕으로 최소한의 코드만 작성하는 실천 방법이다.
•
켄트 벡이 세운 단순한 설계의 규칙은 다음과 같다.
1.
모든 테스트를 통과할 것
2.
의도를 드러낼 것
3.
중복을 없앨 것
4.
구성 요소를 줄일 것
•
규칙의 순서는 실행하는 순서이면서 동시에 중요한 순서이기도 하다.
•
1번은 당연하다. 코드는 테스트를 통과해야 하며 작동해야 한다.
•
2번은 코드가 일단 작동하면 다음으로 표현력 있게 만들어야 한다는 것이다. 프로그래머의 의도를 드러내야 한다.
◦
긴 함수를 작고 적절한 이름을 가진 함수들로 쪼개기도 한다.
•
3번은 가능한 한 이해하기 쉽고 표현력 있게 만들어진 후, 코드 내의 중복을 찾아서 제거해야 한다는 뜻이다.
◦
이 과정 동안 이루어지는 리팩토링은 조금 더 복잡하다.
▪
중복을 제거하는 것이 단순한 경우도 있다.
▪
중복인 부분을 함수로 빼낸 다음, 이 함수를 호출하도록 바꾸기만 하면 될 때도 있다.
▪
디자인 패턴 같은 것들을 적용하기도 한다.
•
4번은 중복을 제거한 후에는 클래스나 함수, 변수 같은 구성 요소의 수를 줄이기 위해 노력해야 한다는 것이다.
설계 무게
•
설계가 복잡할수록 프로그래머에게 주어지는 인지 부하는 늘어난다. 이 인지 부하가 설계 무게다.
•
단순한 설계 방법을 사용하여 끊임없이 시스템의 설계를 리팩토링하라. 그렇게 요구 사항과 설계의 균형을 유지하고 궁극적으로 높은 생산성을 유지하라.
짝 프로그래밍
•
꼭 해야되는 것은 아니다. 누구도 짝 프로그래밍을 강요해서는 안 되며 모든 순간 함께해야하는 것도 아니다.
짝 프로그래밍이란 무엇인가?
•
프로그래밍 문제를 두 사람이 함께 해결하는 행위다.
•
역할을 구분하여 하기도 하며 없이 하기도 한다.
짝 프로그래밍을 하는 이유
•
구성원끼리 지식을 공유하고, 지식의 칸막이가 생기지 않게 만드는 단연코 최고의 방법이기 때문이다.
•
코드 리뷰를 짝 프로그래밍으로 대체하기도 한다.
짝 프로그래밍을 통한 코드 리뷰
•
짝 프로그래밍의 코드 리뷰의 한 형태로 보기도 하지만 더 큰 장점을 가지고 있다.
•
짝 프로그래밍을 하는 동안 자연스럽게 이루어지는 코드 리뷰는 앞으로의 미래를 생각하며 현재 코드의 상태를 검토할 수 있게 한다.
둘이서만?
•
꼭 둘이서만 해야하는 것은 아니다. 재량적으로 필요에 따라 결정하면 된다.
•
셋 이상이 하는 짝 프로그래밍을 몹 프로그래밍이라고도 부른다.
관리자
•
눈살 찌뿌려가며 프로그래머가 같이 있는 것을 탐탁치 않아할 관리자는 잘 없을 것이다.
•
절대, 절대, 절대, 짝 프로그래밍을 허락맡지 말라, 당신은 전문가다. 결정은 당신이 한다.
결론
•
기술 실천 방법은 애자일의 활동 중 가장 핵심적인 요소다.
•
기술 실천 방법 없이 애자일을 도입하려는 시도는 실패할 수 밖에 없다.
◦
애자일의 효율성 덕분에 프로젝트를 아주 빠르게 난장판을 만들 수 있기 때문이다.
•
기술적인 품질을 높게 유지할 수 있도록 돕는 기술 실천 방법이 없다면 생산성이 빠르게 추락하여 죽음의 구렁텅이로 빠지게 될 것이다.
