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

Photo by David Travis on Unsplash

 

비즈니스 실천 방법, 팀 실천 방법에 이어, 클린 애자일 5장은 마지막 동그라미인 기술 실천 방법을 이야기 한다.

기술 실천 방법이 애자일의 진짜 핵심이다.

 

 

<이미지 출처: https://blog.ynkb.xyz/89/ >

 

기술 실천 방법 다음과 같다.

 

테스트 주도 개발(Test-Driven Development): 실패하는 테스트를 짜고, 그 다음에 테스트를 통과하는 코드를 짠다.

리팩터링(Refactoring): TDD를 통해 동작하는 코드를 짜고 나면, 이를 리팩터링 한다.

단순한 설계(Simple Design): 리팩터링 목표중의 하나이다. 최대한 단순하게 최소한의 코드로만 작성하라는 것이다.

짝 프로그래밍(Pair Programming): 두 사람이 함께 프로그래밍을 해나간다.

 

하나하나 자세한 설명이 이어지겠지만, 이들은 유기적으로 연결되어 있다. 막연히 이들 중에서 가능한 것 하나, 툴을 적용해보면 좋겠다 했었는데 최근에서야 이들의 연결성을 어렴푸시 이해하게 되었다. 물론 이 방법들의 껍데기만 베껴내려 하면 안될 것이다. 이러한 방법들로 얻어내려한 진짜 목표가 무엇인지를 생각하고 이해한다면 더욱 나은 방법, 조직에 좀더 맞는 방법을 찾아나갈 수 있을 것이다.

 

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

"테스트 주도 개발은 프로그래머의 복식 부기라고 할 수 있다. 구현해야 하는 동작을 두 번씩 입력한다. 한 번은 테스트로, 그리고 한 번은 이 테스트를 통과하게 만드는 제품 코드로 말이다." 131p

 

TDD의 세 가지 규칙은 다음과 같다.

 

1) 실패하는 테스트 코드를 먼저 짠다.

2) 테스트 코드는 실패 하도록 만드는 것 이상을 쓰면 안된다.

3) 마찬가지로 구현코드도 테스트 통과에 필요한 이상의 코드를 짜면 안된다.

 

언듯 보면 이상해 보이는 이 세 규칙을 계속 반복하며 코드를 짜는 것이다. 이 세 가지 규칙을 잘 지킨다면…

 

"작업하던 코드는 아무리 길어도 1분 전까지는 실행 가능했고, 테스트를 모두 통과했다. (중략) 아무리 길어도 1분 전까지는 모든 것이 작동했다." 133p

 

이 말은 1) 디버깅이 불필요해진다는 이야기다. 문제가 발생하면 방금전에 짠 코드에서 문제가 발생한 것이다. 디버깅을 잘하는 것도 중요하겠지만 디버깅을 할 필요가 없는게 훨씬 낫다. 이것이 TDD를 하면 얻게 되는 첫 번째 이득이다. 나머지 이득도 보자

 

2) 문서화: 테스트 코드는 그 자체가 제품 코드가 어떻게 동작해야 하는지에 대한 설명이고 문서이자 예제이다.

3) 재미: 실패하는 테스트를 통과하게 하는 건 생각보다 훨씬 재미있다.

4) 완벽함: 테스트 코드를 먼저 짜고 그에 맞춰서 제품 코드를 구현하면 코드의 구조가 좋아진다. 사후에 만드는, 테스트 하기 힘든 부분은 어쩔 수 없이 빼버리게 되는, 테스트보다 훨씬 완벽한 테스트 묶음을 가지게 되는 것이다. 참고로, 테스트 커버리지의 수치에 집착하지 말아야 한다. 대략의 상황을 가늠하는 것이지 수치 자체가 목표가 되어서는 안된다.

4) 설계: 위에 이미 설명했지만 테스트를 먼저 짜고 제품 코드를 짜면 다른 말로 테스트하기 쉬운 설계의 코드가 된다. 테스트하기 쉬운 코드란 일반적으로 분리가 잘 된 코드라는 말이다.

5) 용기: 리팩터링, 코드개선을 할 수 있는 용기를 준다. 용기라는 표현은 조금 어색하기는 하다. 개선한다고 까불다가 코드를 깨먹지는 않았는지 확인하기 쉽다는 말이다.

 

리팩터링(Refactoring)

"리팩터링은 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법이다." 140p

 

구조는 왜 개선하는 것일까? 그래야 유지, 보수, 기능 추가가 쉽다. 즉 프로젝트 초기의 생산성이 꾸준히 유지된다. 동작이 바뀌지 않았다는 것은 테스트를 통해 검증한다.

TDD와 리팩터링은 떨어질 수 없는 관계이다.

 

<이미지 출처: https://sanghye.tistory.com/11>

 

1) 먼저 실패하는 테스트 코드를 짜고

2) 테스트를 통과하는 최소한의 코드를 구현한다. 이 시점에서 구현 완성이다.

3) 리팩터링을 한다. 동작을 바꾸지 않았다는 것은 수시로 테스트를 패스하였는지 여부로 확인한다.

4) 1) 2) 3) 을 반복한다.

 

여기에서 중요한 것은 리팩터링이 별개의 작업이 아니라는 것이다. 심지어는 1, 2분 단위로도 위의 빨강/초록/리팩터링이 반복되는 것이다.

 

단순한 설계(Simple Design)

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

 

켄트 벡이 말한 단순한 설계의 규칙 4가지

 

1) 모든 테스트 통과

- 당연히 테스트를 통과해야 한다. 단순하게 설계하였더라도 우리가 원하는 대로 작동해야 하는 것이다.

2) 코드를 보면 의도를 알 수 있어야 한다.

- 한 눈에 뭐하는 코드인지를 알 수 있어야 유지보수가 쉽다.

3) 중복을 없앨 것

- 하나만 고치면 되니 유지보수가 쉽다.

4) 구성 요소를 줄일 것

- 최소한의 구성요소란 분석하고 이해할 거리가 적다는 것이다.

 

"설계의 복잡도와 기능의 복잡도 사이에서 균형을 잡는 것이 단순한 설계의 목표다." 144p

 

짝 프로그래밍(Pair Programming)

목표는 지식을 팀 전체에 퍼뜨리는 것이다. 누구 하나 없어도 잘 돌아가는, 역량과 안정성이 있는 팀이 된다.

또한 애자일 소프트웨어 개발 선언의 "공정과 도구보다 개인과 상호작용을" 에도 부합한다.

 

꼭 해야하는 것 아님.

잠깐만 하는 것임(30%-80% 알아서)

일정도 따로 잡지 않는다.

한명이 운전사, 한명이 항해사로 해도 되고, 둘이 번갈아 해도 된다. 한마디로 알아서 하면 된다.

길어야 하루, 보통은 한두 시간, 짧은 15분도 효과 있음

한 주 단위로 보면 짝 프로그래밍의 절반은 남에게 도움을 받는데, 절반은 남에게 도움을 주는데 써야 한다.

꼭, 둘이서만 하는 건 아니다. 셋, 넷, 그이상도 가능하다. mob programming

 

"그래서 많은 팀에서 코드 리뷰를 짝 프로그래밍으로 대체했다." 147p

"짝 프로그래밍을 코드 리뷰의 한 형태로 볼 수도 있지만, 짝 프로그래밍에는 더 큰 장점이 있다. (중략) 앞으로 코드를 어떻게 바꾸어 가야 할 지를 생각하며 현재 코드의 상태를 검토하게 된다." 147p

 

프로그래밍 자체로 보면 짝 프로그래밍은 15% 비용 증가이지만, 코드 리뷰를 대체한다고 보면 쌤쌤이다.

 

"당신은 전문가다. 당신이 결정하라." 149p

 

짝 프로그래밍을 해도 되는지 허락 받을 필요 없다.