👉 Chapter 5: 기술 실천 방법

• 기술 실천 방법이야말로 애자일의 진짜 핵싐이다.
• TDD와 리팩터링, 단순한 설계, 심지어 짝 프로그래밍도 없다면, 애자일은 원래 의도와는 달리 쓸모없는 빈 껍데기가 되고 만다.

📚 테스트 주도 개발

• 테스트 주도 개발(Test-Driven Development, TDD)은 제대로 설명하려면 별도의 책 한 권 필요할 만큼 이야기할 것이 많고 복잡한 주제이다.
• 테스트 주도 개발은 프로그래머의 복식 부기라고 할 수 있다. 구현해야 하는 동작을 두 번씩 입력한다.
• 한 번은 테스트로, 그리고 한 번은 이 테스트를 통과하게 만드는 제품 코드이다.
• 두 번의 입력은 서로 딱 맞아야 한다.
• 프로그래머는 TDD를 공부할 때, 기능을 한 번에 하나씩만 추가하라고 배운다. 실패하는 테스트 형태로 먼저 하나 추가하고, 이 테스트를 통과하게 만드는 제품 코드 형태로 다시 추가한다. 이렇게 하면 오류를 빠르게 찾을 수 있다.

🔥 TDD의 세가지 규칙

1. 해당 코드가 없어서 실패하는 테스트 코드를 쓰기 전에 제품 코드를 먼저 쓰면 안 된다.
2. 테스트 코드를 쓸 때는 실패하도록 만들기 위해 필요한 것보다 더 많이 쓰면 안 된다. 컴파일 실패도 실패로 간주한다.
3. 실패하는 테스트를 통과시키기 위해 필요한 코드보다 더 많은 제품 코드를 쓰면 안 된다.

🔥 디버깅

• 디버거에 능숙해지는 방법은 실제로 디버깅에 많은 시간을 쓰는 것밖에 없다.
• 디버깅에 많은 시간을 쓴다는 것은 언제나 그만큼 버그가 많다는 것이다.
• 테스트 주도 개발을 하면, 디버거를 쓸 일이 별로 없기 때문에 디버거에 익숙해질 수가 없다.
• 세 가지 규칙을 실천하면 버그의 횟수나 심각한 정도는 크게 줄일 수 있다.

🔥 문서화

• 세 가지 규칙을 따르다 보면 만들어지는 테스트는 전체 시스템의 코드 예제가 된다.
• 테스트는 이 함수를 호출하는 모든 방법을 보여 주고, 이 함수가 던지는 모든 예외를 처리하는 방법을 보여 줄 것이다.
• 테스트는 테스트하는 시스템을 설명하는 문서의 한 형태이다.
• 프로그래머에게 완벽한 형식의 문서가 있다면, 코드 형태일 것이다. 테스트가 바로 그렇다.
• 테스트는 시스템 중 작은 부분의 동작을 설명하는 작고 독립적인 코드 조각일뿐이다.

🔥 재미

• 세 가지 규칙을 따라서 테스트를 먼저 작성ㅇ하면 재미있다.
• 시간 때우기가 아니라 무언가 작동하게 만드는 일 같이 느껴질 것이다.

🔥 완벽함

• 테스트를 만들기 힘든 이유는 테스트 가능 여부를 생각하지 않으면서 코드를 작성하고, 설계할 때도 테스트를 고려하지 않았기 때문이다.
• 테스트에 구멍을 남겨놓게 되어 나중에 돌아와서 다시 작성하면 된다고 자기 합리화를 한다.
• 테스트를 통과했다면 배포할 결정을 내릴 수 있다.
• 어쨌든 아무리 성실하게 세 가지 규칙을 따르더라도 100% 완벽한 테스트 묶음이 만들어지지는 않는다. 하지만 배포를 위해 꼭 100%의 완벽함이 필요한 것은 아니다. 커버리지(coverage)가 90%대 후반 정도면 충분할 것이다. 그리고 이 정도는 당연히 달성할 수 있다.

• 테스트 커버리지는 팀 내부용 지표이지 관리 지표가 아니다. 관리자는 아마 이 숫자가 어떤 의미인지 제대로 알지도 못할 것이다.
• 관리자는 테스트 커버지를 목표나 목적으로 삼아서는 안 된다. 테스트 커버리지는 팀의 테스트 전략을 확인하기 위해서만 사용해야 한다.
• 커버리지가 낮다고 빌드에 실패한 것으로 보아서는 안 된다. 이렇게 하면 프로그래머는 커버리지를 높이기 위해 단언문도 없이 테스트를 넣어 버릴 것이다.
• 코드 커버리지는 코드와 테스트에 대한 깊은 지식이 있어야 이해할 수 있는 복잡한 주제다. 절대 관리용 지표로 삼아서는 안 된다.

🔥 설계

• 테스트를 먼저 쓰면 테스트하기 힘든 함수는 쓸 수가 없다.
• 테스트를 먼저 쓰기 때문에 테스트하기 쉬운 설계가 나오는 것은 당연하다.
• 함수를 테스트하기 쉽게 유지할 수 있는 법은 결합을 끊고 분리하면 된다. 테스트할 수 있다는 것은 분리했다는 것과 같은 뜻이다.

🔥 용기

• 세 가지 규칙은 디버깅을 줄일 수 있고, 프로그래머에게 알맞은 좋은 품질의 문서가 생기고, 재미있는 데다가 완벽함도 얻을 수 있고, 시스템도 잘 분리된다.
• 하지만 이런 혜택은 어디까지나 부차적인 것이고 TDD를 하는 진정한 이유는 용기이다.
• 엉망인 코드를 수정할 때 코드가 망가질 것이라는 생각때문에 뒷걸음질 치게 된다. 그래서 코드를 정리하는 데 실패한다.
• 완벽한 테스트 묶음이 있어서 테스트가 통과하는 경우에는 문제가 없을 거라고 안심할 수 있는 상황이라면 어떻게 됐을까?
• 완벽한 테스트 묶음이 있으면 코드를 고치는 두려움이 사라진다. 코드를 정리하는 두려움이 사라진다. 따라서 코드를 정리할 것이다.
• 이것이 TDD를 하는 이유고 TDD는 용기를 준다.

📚 리팩터링

• 리팩터링은 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법이다.
• 프로그램은 동작은 테스트로 정의한다. 다시 말해서, 테스트를 깨먹지 않으면서 이름이나 클래스, 함수, 표현식을 변경하는 것이다. 동작에 영향을 주지 않으면서 시스템 구조를 개선한다.
• 그렇기 때문에 당연히 리팩터링은 TDD와 밀접한 관련이 있다. 두려움 없이 코드를 리팩터링하려면, 무언가 깨 먹지 않았다는 확신을 얻을 수 있는 테스트 묶음이 필요하다.

🔥 빨강/초록/리팩터링

• 본질적으로 리팩터링은 TDD의 세 가지 규칙을 반복함으로써 이루어진다.
• 리팩터링에서는 빨강/초록/리팩터링 주기라고 부른다.

1. 먼저, 실패하는 테스트를 만든다. (Red)
2. 그리고 이 테스트를 통과하게 만든다. (Green)
3. 그리고 코드를 정리한다. (Refactoring)
4. 1단계로 돌아간다.

• 여기서 핵심은 프로그래밍이라는 과업을 작동하는 코드를 쓰는 것과 코드 정리하기라는 두 가지 다른 측면으로 분리한 것이다.
• 리팩터링이라는 단어가 일정에 나타나서는 안 된다. 리팩터링은 계획을 잡고 하는 활동이 아니다.
• 리팩터링할 시간을 따로 할당해서도 안 된다.
• 리팩터링은 소프트웨어를 작성할 때 몇 분마다, 혹은 몇 시간마다 하는 일상적인 작업의 일부일 뿐이다.

🔥 더 큰 리팩터링

• 가끔은 요구 사항이 바뀌어서 현재의 설계나 구성이 더는 최적이 아니게 될 수가 있다. 그래서 시스템 구조를 꽤 많이 바꿔야 할 수도 있다.
• 이런 변경도 빨강/초록/리팩터링 주기 안에서 일어나야 한다.

📚 단순한 설계

• 단순한 설계(Simple Design) 실천 방법은 리팩터링의 목표 중 하나다.
• 단순한 설계는 최대한 단순하고, 작고, 표현력이 뛰어난 구조를 바탕으로 최소한의 코드만 작성하는 실천 방법이다.

1. 모든 테스트를 통과할 것
2. 의도를 드러낼 것
3. 중복을 없앨 것
4. 구성 요소를 줄일 것

• 1번은 자명하다. 코드는 테스트를 통과해야 한다. 코드는 작동해야 한다.
• 2번은 코드가 일단 작동하면 다음으로 표현력 있게 만들어야 한다는 것이다. 의도를 들어내야 한다. 이 규칙 때문에 간단하고 보기 좋게 만들기 위한 리팩터링을 많이 하게 된다.
• 3번은 코드가 가능한 한 이해하기 쉽고, 표현력 있게 만들어진 후, 코드 내의 중복을 찾아서 제거해야 한다는 뜻이다. 이 과정 동안 이루어지는 리팩터링은 조금 더 복잡하다.
• 4번은 중복을 제거한 후에는, 클래스나 함수, 변수 같은 구성 요소의 수를 줄이기 위해 노력해야 한다는 것이다.
• 단순한 설계의 목표는 코드의 설계 무게를 가능한 한 가볍게 만드는 것이다.

🔥 설계 무계

• 설계가 복잡해질수록 프로그래머가 느끼는 인지 부하는 늘어난다. 이 인지 부하가 설계 무계다.
• 설계가 무거울수록 시스템을 이해하고 수정하기 위해 프로그래머가 들이는 시간과 노력은 늘어난다.
• 설계의 복잡도와 기능의 복잡도 사이에서 균형을 잡는 것이 단순한 설계의 목표이다.
• 단순한 설계 실천 방법을 사용하여 끊임없이 시스템의 설계를 리팩터링한다.

📚 짝 프로그래밍

• 일단 먼저 짝 프로그래밍을 꼭 해야 하는 것은 아니다. 누구도 짝 프로그래밍을 강요해서는 안 된다.
• 짝 프로그래밍은 잠깐식 하는 것이다.
• 짝 프로그래밍이 차지하는 업무 비중은 50% 정도가 좋다.

🔥 짝 프로그래밍이란 무엇인가?

• 짝 프로그래밍은 프로그래밍 문제 하나를 두 사람이 함께 해결하는 행위이다.
• 짝 프로그래밍을 할 때 각자 역하를 나누기도 한다. (한 명이 운전자 역할을, 다른 한 명이 항해사 역할 등.)
• 핑퐁이라고도 부른 방식은 먼저 한 명이 테스트를 만든다. 그러면 다른 사람은 짝이 쓴 테스트를 통과하도록 만든 뒤, 새로운 테스트를 추가하고 다시 짝에게 넘긴다.
• 하지만 특별한 역할 구분 없이 하는 경우가 제일 많다. 프로그래머들은 마우스와 키보드를 공유하며 서로 힘을 모아 동등한 관계에서 코드를 작성한다.
• 짝 프로그래밍은 일정은 따로 잡지 않는다.
• 짝을 지어 일하는 시간은 일반적으로 길지 않다. 대부분 한두 시간 안에 끝내야 한다.
• 짝이 스토리를 담당하지는 않는다. 짝이 아니라 프로그래머 한 명 한 명이 스토리를 완성할 책임을 져야 한다.
• 짝 프로그래밍의 목표는 지식을 모으는 것이 아니라 퍼트리고 교환하는 것이다.

🔥 짝 프로그래밍을 하는 이유

• 매 순간 협력하며 일한다.
• 짝 프로그래밍은 구성원끼리 지식을 공유하고, 지식의 칸막이가 생기지 않게 만드는 단연코 최고의 방법이다.

🔥 짝 프로그래밍을 통한 코드 리뷰

• 짝 프로그래밍을 하는 동안 두 프로그래머는 코드를 함께 작성하게 된다.
• 이 과정에서 새로운 코드를 쓰기 위해 자연스럽게 기존의 코드를 보고 리뷰하게 된다. 따라서 짝 프로그래밍에서 이루어지는 리뷰는 팀의 코드 규칙을 지켰는지 확인하는 기계적인 검가사 아니다.
• 앞으로 코드를 어떻게 바꾸어 가야 할지를 생각하며 현재 코드의 상태를 검토하게 된다.

🔥 비용은?

• 짝 프로그래밍의 비용은 측정하기 어렵다.
• 가장 눈에 띄는 비용은 하나의 문제를 풀기 위해 두 사람이 일한다는 것이다.
• 직접적인 비용 증가는 15% 정도라고 한다.
• 업무 시간의 50%를 짝을 지어 일한다고 가정하면, 대충 생산성이 8% 정도이다.
• 그리고 서로 가르쳐 주며 이루어지는 지식 교환이나, 강도 높은 협업에서 오는 이득도 고려해야 한다.

🔥 둘이서만?

• 보통은 둘이서 하지만, 꼭 그래야 하는 것은 아니다.
• 가끔은 셋이나 넷, 혹은 더 많은 사람이 하나의 문제를 함께 해결할 수도 있다.
• 셋 이상 하는 짝 프로그래밍을 몹 프로그래밍이라고도 부른다.

🔥 관리자

• 절대, 절대, 절대, 짝 프로그래밍을 해도 되는지 허락받지말라.
• 아니면 테스트를 해도 되는지, 아니면 리팩터링을 해도 되는지 등등... 당신은 전문가다. 당신이 결정하라.