7. 기술적 실행 관례

💡 해당 책은 수필 느낌의 성격이 강하며 챕터 하나의 분량이 약 30페이지로 상당히 짧습니다. 그렇기에 포스팅이 다소 짧을 수 있습니다. 아래는 제가 책을 읽으며 가슴에 와닿은 내용들입니다.

---

올바른 일 vs 올바른 실행

• 애자일 방법론의 절차 중심적인 부분들은 우리가 비즈니스 목표에 맞게 가고 있는지 정기적으로 살펴볼 수 있는 피드백 루프를 만들어 준다.
• 애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 우리가 '올바른 일'을 실행하고 있는지 점검하도록 도와준다.
• 기술적 실행 관례들은 우리가 일을 '올바르게 '하고 있는지 알 수 있게 해준다.

실행 관계와 가치

• XP 실행 관례들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공한다.
• 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다. 
• XP 실행 관례로부터 성과를 얻으려면 진심으로 받아들이고 내재화해야 한다. 실행 관례를 꾸준히 실행하지 않고 부분적으로 하다가 안 한다면 그것이 실제 효과가 있는지는 알 수가 없다.
• 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다.

자동화된 테스트

• 자동화된 테스트가 있다면 코드를 수정한 지 몇 분만에 안심하고 상용 릴리즈에 반영할 수 있다.
• 자동화된 테스트는 실제 측정 가능한 비즈니스적 가치를 가져다 준다.

테스트 먼저

• 테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩하도록 유도하여 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다.

지속가능한 통합

• 지속적인 통합은 TDD와 함께 수행되어 이러한 피드백 루프를 단 몇 분으로 줄일 수 있다.

페어 프로그래밍

• 페어 프로그래밍을 하면 코드가 작성되자 마자 그 품질에 대해 피드백을 받을 수 있다.
• 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.

리펙토링

• 지속적으로 코드를 리팩토링하면 이러한 위험이 줄어든다.
• 리팩토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.

실용주의

• 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야한다.
• 무언가를 절대적인 진리로 바라보는 것은바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.