선배 개발자와 페어프로그래밍 하며 받은 조언입니다.

1. 작업의 단위를 잘게 쪼개라

가능한 작업의 단위를 잘게 쪼개서 체크리스트를 만들어라. 각 작업의 단위는 5분~10분이면 좋다. 각각의 작업을 해결해 나갈 때 마다 과감히 체크리스트에서 지워내려가라. 타격감이 성취감으로 이어질 것이다. 만약 진행한 작업이 생각보다 길었다면 더 작은 단위로 쪼갤 수 있었는지 복기해봐라. 혹은 놓친 위험요소나 방해요소가 있지는 않았는지 복기해봐라.

2. 앞에서 하는 작업이 뒤에서 하는 작업에 도움이 되도록 쪼개라.

A - B - C - D - E 의 순서로 linear 하게 작업을 진행한다면, E 라는 마지막 결과물이 나오기 전까지 앞서 진행했던 A~D 의 결과를 확인할 수 없다. 결과적으로 도달하고 싶은 목표가 복잡할수록 이러한 방식은 사고 정지와 작업 지연을 불러 일으킬 확률이 높다. 또한 뒤의 작업을 진행하다가 앞의 작업을 수정해야한다거나, 필요없는 작업이었다거나 하는 경우에는 시간을 낭비했다는 것을 뒤늦게 깨닫게 될 수도 있다.

A1 - A2 - A3 - A4 - A5 의 순서로 작업을 진행하자. 이게 무슨 말장난같은 소리인가? 설명하자면 이렇다. 우선 A1 만 해도 동작할 수 있는 최소한의 결과물을 만들자. 복잡한 기능은 다 떼고 가장 간단한 동작부터 시작해도 좋다. 그 후에 A2 를 만드는 그 다음 단계로 나아가자. 이 때 A1 에 기능을 수정하거나 추가하여 A2 를 만들 수 있도록 한다. 이렇게 버전 업그레이드를 해 나가는 느낌으로 A3, A4 를 만들어 나가면 훨씬 쉽고 빠르게 목표를 달성할 수 있을 것이다.

예시를 들자면, 하늘을 나는 자동차를 만들고 싶을 때
타이어 - 몸체 - 날개 - 조립 - 완성 의 과정과
작동하는 엔진 - 엔진으로 움직이는 4륜 - 움직이는 자동차 - 뜨는 자동차 - 하늘을 나는 자동차 의 과정 으로 비유할 수 있겠다. 맞는 비유인지는 모르겠지만..?

3. 가능한 빠르게 결과물이 나올 수 있도록 한다.

어떤 작업을 할 때, 그 작업으로 인한 결과물을 가능한 빠르게 확인할 수 있으면 좋다. 여기서의 결과물은 최종적으로 원하는 결과물이 아니라, 그보다 훨씬 단순한 형태여도 괜찮다. 결과물이 나왔다는 것은 목표 달성 조건이 명확하게 있었다는 것의 반증이다. 또한, 결과물을 달성할만큼의 작업만 하도록 집중할 수 있다. 이는 불필요한 작업을 방지하는 효과가 있다.

4. 프로젝트 코드가 빌드되지 않는 시간을 최소화해라.

이 조언은 정적 타입 언어에만 적용될 수도 있다.
코드를 수정하면 기존 코드가 깨지기 시작하며 프로젝트 코드가 빌드되지 않을 것이다. 깨진 코드들을 전부 고치고 나서야 다시 빌드가 될 것이다. 이 사이의 시간이 길어질수록 좋지 않다. 작업이 길어지고있다는 증거다. 기능을 완벽하게 완성하지 못했다고 하더라도 (= 동작이 실패하는 경우가 있더라도) 일단 코드가 죽지 않고 동작할 수 있는 상태를 만들자. 다만, 동작이 실패한다면 의도하거나 예측한대로 실패하는지를 확인해가며 작업해야 할 것이다.