소프트웨어 장인 :: 7장 기술적 실행 관례

기술적 실행 관례의 적용

 이번 장에서는 '소프트웨어 장인으로서, 최선의 기술, 도구, 절차, 방법론 그리고 TDD나 페어 프로그래밍 같은 기술적 실행 관례를 올바르게 선택할 수 있는 능력을 가져야 함'을 말한다. 보통 기술적 실행 관례는 소프트웨어를 더 긍정적으로 관리하기 위해 등장한다. 그렇지만 꼭 기술적 실행 관례들을 적용해야만 하는 것은 아니다. 모든 것은 상황에 맞아야 그 의미가 있는 법이다. 소프트웨어 개발자 경험이 적은 사람은 시야가 좁은 경우가 많기 때문에 새로운 기술적 실행 관례를 맹신하여 그것을 당장 실무에 적용하고 싶어 할 수 있다. 그렇지만 현재의 관례가 더 나을 수도 있음을 알아야 한다.

기술적 실행 관례를 적용하기 위해서 필요한 자세

 일단 지금이 특정 기술적 실행 관례를 적용해야 하는 적기라고 판단되면, 그 관례를 적용하기 위해 동료들을 설득해야 한다. 동료로는 개발자도 있을 수 있고 기획자도 있을 수 있다. 그들에게 이 관례의 특징에 대해 설명하는 것보다 이 관례를 적용함으로써 우리에게 어떤 직접적인 편리함 혹은 이익이 있을지 설명해 보자. 이 관례를 도입해서 어떤 점이 달라지는지를 먼저 이해시킬 수 있다면 이 관례를 도입할 수 있을 확률이 매우 높아질 것이다.

'TDD, 지속적인 통합, 페어 프로그래밍, 리팩토링'이 가져올 이익

 이 책에서는 기술적 실행 관례의 예시로 'TDD, 지속적인 통합, 페어 프로그래밍, 리팩토링'을 든다. 이 관례들에 대한 설명과 도입했을 때 얻을 수 있는 직접적인 이익들도 같이 설명한다. 그중 인상 깊은 문장 2개를 가져와봤다.

같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

몇 년 동안 바뀐 적이 없는 부분을 리팩토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 이팩토링해야 할 이유도 없다. 리팩토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.

요즘 페어 프로그래밍과 리팩토링을 자주 하는데, 위 문장들을 한번 실천해 봐야겠다.