실용주의 프로그래머 9

실용주의 프로젝트

프로젝트의 주제를 개인의 철학과 코딩에서 논점을 옮겨, 프로젝트 전체 차원에서 바라보자.

실용주의 팀

실용주의 팀은 어떤 특징을 가질까? 실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다.
실용주의 팀은, 팀 전체가 깨진 창문을 용납하지 않는다. 개발의 품질을 지키기 위해서 팀원 모두가 기여한다. 문제를 발견했을 때, 누군가가 처리하기를 기대하지 않고 항상 적극적으로 환경 변화를 감시한다. 변화를 거부하기보다 수용하며 파악한다.
구형 시스템 유지 보수, 프로세스 회고와 개선, 새로운 기술 탐험, 학습 및 기술 갈고 닦기와 같은 할일들을 항상 계획하며 실천해야 한다. 그리고 무엇보다 팀의 개발자들끼리 서로 소통한다. 팀 이름을 갖고, 제품의 내부 이름을 짓는다. 서로 관심을 갖고 유기적인 소통으로 반복적인 작업을 제거한다.

모든 기능을 갖춘 팀을 조직하라.

코드를 끝에서 끝까지 점진적이고 반복적으로 쌓아 올릴 수 있는 팀을 만들어야 한다. 팀이 하는 모든 일을 자동화할 수 있어야 한다. 도구 제작 역량을 팀 내에 갖추어라.

코코넛만으로는 부족하다.

형식을 흉내냈지만, 내용은 빠트리는 화물 숭배를 경계해야 한다. 스크럼, 에자일과 같은 도구만 사용하고 이름만 붙인다고 실제로 그것이 되는 것은 아니다. 스포티파이, 넷플릭스의 정책과 프로세스를 따라한다고 그들이 될 수는 없다.

유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.

그들이 현재 그런 프로세스를 사용했다고 앞으로 수년간 그런 프로세스를 사용할지는 모르는 일이다. 더 성숙하고, 사업 방향이 번성항에 따라 또 다른 방식을 사용할 것이다. 이것이 그들의 성공 비결이다.
진짜 목표를 찾아야 한다. 진짜 목표는 스크럼을 한다, 애자일을 한다, 린을 한다 같은 종류가 아니다. 진짜 목표는 소프트웨어를 제공함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 하는 것이다. 필요할 때마다 출시하며, 사용자가 필요할 때 제공할 수 있도록 해야 한다.

실용주의 시작 도구

일상적인 작업은 모두 자동화해야 한다. 그래서 지원되는 모든 컴퓨터에서 반복 수행할 수 있어야 한다. 어떤 작업을 하든 필요한 가장 기본적이고 중요한 요소가 3가지 있다. 버전 관리, 회귀 테스트, 전체 자동화다.

버전 관리

버전 관리로 운용해야 한다. 프로젝트 차원에서 버전 관리 시스템이 빌드와 릴리스 프로세스를 운용할 수 있어야 한다. 릴리스 절차가 훨씬 더 간단해져서 일상의 일부가 된다.

가차 없고 지속적인 테스트

버그 찾기는 그물 낚시와 비슷하다. 잔챙이를 잡기 위해 촘촘한 그물을 쓰기도 하고, 식인 상어를 잡기 위해 크고 성긴 그물을 쓰기도 한다. 작은 잔챙이를 잡기 위한 단위 테스트와, 상어를 잡기 위한 통합 테스트를 구축해야 한다.

모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.

최종 사용자의 요구 사항을 충족하는지도 관심을 가져야 한다. 최종 사용자의 접근 방식과 사용 방식에 궁금해하고, 그것이 개발자의 테스트 데이터와 어떻게 다른지 이해해라. 성능 테스트도 프로젝트의 중요한 측면이다.
테스트를 테스트하는 것도 중요하다. 어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생긴 경우에 테스트가 경보를 울리는지 확인하라. 더 높은 차원에서는 넷플릭스의 카오스 멍키 같은 도구를 사용하여 서비스에 일부러 지장을 일으키고, 애플리케이션의 회복 능력을 테스트하라.
커버리지 분석도 좋지만, 그것을 맹신해서는 안된다. 중요한 것은 프로그램이 갖는 상태의 개수다. 예외적인 상태를 감지하고 확인할 수 있어야 하지만 이것은 어려운 문제다. 그것을 해결하기 위해 속성 기반 테스트를 고려해봐라.
테스트에서 가장 중요한 개념은 버그를 한 번만 잡는 것이다. 한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안된다.

전체 자동화

수작업 절차를 사용하지 말라

사람들은 컴퓨터처럼 같은 일을 반복할 수 없고, 그런 것을 기대해서도 안된다. 모든 것이 자동화에 의존해야 한다. 수작업 단계를 하나라도 넣는 순간, 커다란 창문을 깨트리는 것이다.

사용자를 기쁘게 하라

개발자로서 우리의 목표는 사용자를 기쁘게 하는 것이다. 사용자가 기대하는 바를 충족시켜라. 이런 질문을 던지는 것도 좋다.

이 프로젝트가 끝나고 우리가 성공했는지 어떻게 알 수 있을까요?

기대를 알면, 어떻게 기대를 충족시킬 수 있을지 고민을 시작할 수 있다. 고객을 기쁘게 하고 싶다면 고객이 문제를 풀 때 적극적으로 도와줄 수 있는 관계를 구축하라. 우리는 문제 해결사다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다.

오만과 편견

실용주의 프로그래머는 책임을 회피하지 않는다. 도전을 수용하고, 자신의 전문성이 널리 알려지는 것을 기뻐한다. 설계 혹은 코드를 맡는다면 자신이 보기에 자랑스러운 작품을 만들어낸다.

자신의 작품에 서명하라

다른 사람의 코드를 존중하고, 다른 개발자를 존중하라. 사람들이 코드에 붙은 여러분의 이름을 보고 그것이 튼튼하고 잘 작성됐으며 제대로 테스트됐고, 훌륭히 문서화됐을 것이라고 기대하게 하자. 이것이 실용주의 프로그래머다.