The Pragmatic Programmer의 마지막 장은 개인의 습관을 팀과 프로젝트로 확장합니다.
앞의 장들이 좋은 개발자의 태도를 말했다면, 8장은 좋은 팀이 그 태도를 어떻게 반복 가능한 운영 체계로 만드는지
묻습니다.
가장 먼저 떠오른 것은 자동화입니다.
자동화는 단순히 시간을 아끼는 도구가 아닙니다.
팀의 기억입니다.
사람이 매번 기억해야 하는 절차는 언젠가 빠집니다.
빌드, 테스트, 배포, 문서 생성, 블로그 발행 같은 반복 작업은 자동화될수록 팀의 실수가 줄어듭니다.
테스트도 마찬가지입니다.
테스트는 불신의 표현이 아니라 자신감을 만드는 장치입니다.
가혹할 만큼 꾸준한 테스트는 개발자를 느리게 만드는 것이 아니라, 바꿀 수 있는 용기를 줍니다.
특히 AI가 만든 코드가 늘어날수록 테스트는 더 중요해집니다.
생성 속도가 빨라질수록 검증 하니스도 빨라져야 합니다.
이 장에서 가장 좋아하는 문장은 결국 모든 것이 글쓰기라는 생각입니다.
커밋 메시지, 이슈, 명세, 테스트 이름, README, 블로그 글은 모두 팀이 생각을 공유하는 방식입니다.
글을 못 쓰는 팀은 설계를 오래 유지하기 어렵습니다.
코드 밖의 문장이 흐리면 코드 안의 의도도 흐려집니다.
기대 관리도 제품 품질의 일부입니다.
사용자는 단순히 기능을 받는 것이 아니라 약속을 받습니다.
무엇이 가능하고 무엇이 아직 아닌지, 언제 어떤 품질로 도착하는지 설명하는 능력은 개발의 바깥일이 아닙니다.
마지막으로 자부심입니다.
자부심은 완벽주의가 아닙니다.
내가 만든 결과물에 이름을 걸 수 있는가를 묻는 태도입니다.
오늘 내가 적용할 행동은 반복 작업 하나를 자동화 목록에 올리고, 테스트 실패를 팀의 학습 기록으로 남기고, 커밋
메시지와 문서를 조금 더 읽히게 다듬는 것입니다.
실용주의 프로젝트는 개인의 재능보다
팀의 반복 가능한 운영 습관에 기대어 오래 갑니다.