클린 애자일 다시 읽기 - 5장 기술 실천 방법

개요

기술 실천 방법이야말로 애자일의 진짜 핵심이기 때문이다. p130

• 테스트 주도 개발 - Test-Driven Development(TDD)
• 리팩터링 - Refactoring
• 단순한 설계 - Simple Design
• 짝 프로그래밍 - Pair Programming

기술 실천 방법

테스트 주도 개발 - Test-Driven Development(TDD)

테스트 주도 개발의 동기와 도입 이유를 알아보자.

복식 부기 - Double-entry Bookkeeping

기호 하나만 틀려도 큰일 날 수 있는 프로그래머. 또 다른 직업으로는 회계사가 있다.

복식 부기에서는 모든 거래를 대변과 차변에 적어서 각 변의 합이 같아야 한다. 회계 공부의 초기에는 거래 하나씩을 적고, 양 변의 합이 같은지 매 번 검증한다. TDD는 프로그래머의 복식 부기이다. 차변에 테스트, 대변에 코드를 작성하고 테스트가 성공하는지 확인하는 것이다. 복식부기가 회계의 오류를 방지하듯 TDD는 코드의 오류를 방지한다.

TDD의 세 가지 규칙

1. 실패하는 테스트 코드를 먼저 작성한다.
2. 테스트코드는 딱 필요한 만큼만 실패하도록 작성한다. → YAGNI
3. 코드는 테스트를 통과할 만큼만 작성한다. → YAGNI

디버깅

이렇게 짧게 반복하면 실패하는 순간에 들여다봐야할 코드의 양이 정말 적다. 디버깅을 할 필요가 없어진다.

디버깅은 선망할 만한 기술이 아니다. 디버거에 능숙해지는 방법은 실제로 디버깅에 많은 시간을 쓴 것밖에 없다. p134

문서화

TDD의 세 가지 규칙을 따르면서 만들어지는 테스트는 그 자치가 바로 코드 예제이자 문서이다. 테스트는 심지어 매 번 코드와 함께 업데이트 된다. 또한 테스트는 서로 의존하지 않는다. decoupling

재미

테스트를 먼저 작성하면 재미있다. 코드를 다 짜고 테스트를 짜면 재미가 없다.

완벽함

이것이 우리의 목표다. 우리는 시스템을 배포해도 되는지 알려 주는 자동화된 테스트 묶음을 만들고 싶다. p136

테스트 묶음이 완벽하다는 말의 의미는 무엇일까? 테스트를 통과하면 배포해도 된다는 믿음을 주는 것이다. 그렇기에 테스트 커버리지는 관리 지표가 아님을 주의하자. 즉, 팀장이 테스트 커버리지 70%는 유지해야 한다는 식의 목표가 되어서는 안된다는 것이다.

설계

테스트부터 짜면 그에 맞춰서 구현을 하게 된다(반대로 코드부터 짜면 종종 테스트를 작성하기 어렵다). 그렇게 구현하면 의존성이 적어진다(decoupling). 의존성이 적은 설계가 이루어진 것이다.

용기

“건드리면 안 돼!” 왜냐하면 건드리는 순간 망가질 것이기 때문이다. 망가뜨리는 순간 당신의 코드가 되기 때문이다. 결국 당신은 코드로부터 뒷걸음질 치고, 영망인 코드가 곪아 터지도록 놔둔다. p138

너무나 실감나는 문장이라 인용해둔다. 코드 한 부분의 오류를 보았더라도 이게 어디와 얽혀있는지 자신할 수 없기에 시간이 충분하지 않으면 차마 건드리지 못한 경우가 많았다. TDD는 우리에게 용기를 준다.

리팩터링 - Refactoring

1. 빨강 - 실패하는 테스트
2. 초록 - 코드를 작성하여 테스트를 통과한다. 어떤 수를 써서라도
3. 리팩터링 - 코드를 정리한다.

여기서 2번과 3번을 보자. 키워드는 분리이다. 코드의 작성과 정리를 분리하는 것이다.

단순한 설계 - Simple Design

단순한 설계는 리팩터링의 목표이다.

중간 정리

1. 테스트 주도 개발로 테스트 먼저 코드 나중으로 기능을 구현한다.
2. 리팩터링으로 코드를 다듬는다.
3. 리팩터링의 궁극적인 목표는 단순한 설계이다.

단순한 설계의 규칙 - 켄트 벡

1. 모든 테스트를 통과한다 → 작동하는 코드
2. 의도를 드러낸다 → 읽기 쉬운 코드. 가독성
3. 중복을 없앤다 → 같은 기능을 하는 코드가 여기저기 있으면 수정은 어떻게 하나?
4. 구성요소를 줄인다 → 마찬가지로 관리할 것들을 줄인다.

설계와 기능의 복잡도 타협

복잡한 요구사항은 복잡한 설계로 단순화할 수 있지만 적절한 설계로 타협할 수도 있다.

ex. 관리자 페이지에서 자주 사용하지 않는 기능이라면 요구사항을 조금 덜 만족하는 대신 설계와 구현의 복잡도를 줄일 수 있다.

이러한 타협과 균형으로 추구하는 것은 높은 생산성의 유지이다.

짝 프로그래밍 - Pair Programming

• 짝 프로그래밍의 비중은 정답이 없다. 케바케이다.
• 짝 프로그램의 목표는 지식을 퍼뜨리는 것이고, 지식을 나누는 것이다. → 고급-초급 프로그래머가 짝을 이루는게 더 좋은 이유이다.
• 버스 팩터, 로또 팩터를 없애는 효과도 있다. 갑작스런 결원에도 팀은 돌아간다.
• 훈수 효과도 있다. 둘이 보면 더 낫다.
• 코드 리뷰의 효과도 있기에 생산성 측면에서도 결코 나쁘지 않다.

프로그래머가 결정한다.

짝 프로그래밍을 할지 여부는 당신이 결정한다. 당신이 전문가이다.

결론

기술 실천 방법은 기술의 품질을 높게 유지시켜 준다. 높은 기술 품질은 높은 생산성을 유지시켜 준다.