http://www.extremeprogramming.org/map/code.html
XP flow chart
Copyright 1999 Don Wells all rights reserved
www.extremeprogramming.org
페어 프로그래밍 (Pair Programming)
- 운영에 내보낼 모든 코드를 컴퓨터 한 대에서 두 명이 함께 작업한다.
- 페어 프로그래밍은 개발 시간에 영향을 주지 않으면서 소프트웨어의 품질을 향상시킨다.
- 직관에 반하는 것 같지만, 두 명이 함께 작업하는 것은 각자 작업하는 것만큼 많은 기능을 추가시킬 수 있으면서 품질도 훨씬 좋다.
- 품질이 향상되면 프로젝트 후반부에 비용이 크게 절감된다.
- 페어 프로그래밍을 하는 가장 좋은 방법은 모니터 앞에 나란히 앉는 것이다.
- 두 프로그래머 모두 작성 중인 코드에 집중한다.
- 페어 프로그래밍은 배우는 데 시간이 걸리는 사회적 기술이다.
- 회사 내에서의 지위에 관계없이 양 파트너가 보다 협력적으로 주고 받는 작업을 수행할 수 있도록 애를 써야 하기 때문이다.
- 최고의 페어 프로그래머는 "먼저 당신의 아이디어를 구현해보시죠."라고 말할 줄 아는 사람이다.
- 처음부터 사람들이 페어 프로그래밍을 잘할 것이라고 생각하지 말자.
- 모두에게 페어 프로그래밍이 어떤 느낌이어야 하는지를 알려줄 수 있는 경험자가 만약 팀에 있다면 도움이 될 것이다.
- 페어 프로그래밍은 멘토링이 아니다.
- 둘 중 한 사람이 훨씬 경험이 많은 사람일지라도 동등한 위치에서 함께 작업하는 것은 선생님과 제자의 관계가 아니다.
- 페어 프로그래밍에 익숙해지는 데에는 시간이 필요하므로 처음에 너무 어색하게 느낄 필요 없다.
옮겨 다니기 (Move People Around)
- 심각한 지식의 손실과 코딩 병목을 방지하기 위해 프로그래머들 사이를 이리 저리 옮겨다녀야 한다.
- 만약 팀에서 주어진 영역에 대해 단 한 사람만 작업을 할 수 있다면, 그 사람이 떠나거나 할 일이 너무 많을 때 전체 프로젝트의 진척이 기어가는 것을 발견할 수 있을 것이다.
- 교차 훈련(cross training)은 지식이 고립되는 것을 방지하려는, 손실에 매우 민감한 회사에서 중요한 고려 사항이 되곤 한다.
- 페어 프로그래밍을 하며 코드를 베이스로 사람들을 옮겨다니면 교차 훈련이 될 것이다.
- 주어진 부분에 대해 한 사람이 모든 것을 알게 하기 보다 모두가 각 부분에 대해 최대한 많이 알 수 있게 하자.
- 모두가 시스템의 모든 부분에 대해 충분히 알고 있는 팀은 훨씬 유연할 것이다.
- 별로 할 일이 없는 와중에 몇 명만 과부하가 걸리는 것이 아니라 팀 전체의 생산성이 좋아질 것이다.
- 시스템의 가장 핫한 영역에 개발자를 얼마든지 투입할 수 있게 된다.
- 이런 유연한 로드 밸런싱은 매니저의 꿈이 현실이 되는 것이다.
- 단순한 방법으로, 모두가 각 이터레이션(스프린트 등)의 일부분에서나마 시스템의 다른 영역에서 작업해보도록 권장해보자.
- 페어 프로그래밍을 하면 생산성 손실 없이 가능할 것이다. 또한 사고의 연속성도 보장해줄 수 있다.
- 만약 페어 중 한 사람이 새로운 파트너와 하기를 원한다면 다른 한 사람은 교체될 수도 있다.
무자비한 리팩토링 (Refactor Mercilessly)
- 우리 컴퓨터 프로그래머들은 우리의 소프트웨어 설계가 다루기 어려워진 후에도 한참을 붙들고 있는다.
- 우리는 어떻게든 동작한다는 이유로, 수정하기 두렵다는 이유로 유지하기 어려운 코드를 계속 사용하거나 재사용한다.
- 그런데 그렇게 하는 것이 과연 비용상 효율적일까?
- 익스트림 프로그래밍(Extreme Programming, XP)은 그렇지 않다는 입장이다.
- 불필요한 것들을 삭제할 때, 미사용 기능을 제거할 때, 구식의 설계들을 신식으로 교체할 때 우리는 리팩토링하는 것이다.
- 프로젝트의 생애주기 전반에 걸쳐 리팩토링 하는 것은 시간을 절약해주고 품질을 향상시켜준다.
- 무자비하게 리팩토링하여 설계를 단순하게 유지하고 불필요한 혼란과 복잡성을 피하도록 하자.
- 코드를 깨끗하고 간결하게 유지하여 이해하기 쉽게, 수정하기 쉽게, 그리고 확장하기 쉽게 만들자.
- 모든 것은 딱 한 번만 표현되도록 하자. (중복된 코드가 없도록 하자)
- 결국에는 잘 정비된 시스템을 생산해내는 데 시간이 덜 들어갈 것이다.
- 리팩토링에는 어느정도의 직관(Zen1)이 필요하다.
- 아마 처음에는 힘들 것이다. 왜냐하면 우리가 구상중이던 완벽한 설계를 버리고 리팩토링 과정에서 우연히 발견한 설계를 받아들여야하기 때문이다.
- 틀림없이 구상중이던 설계는 좋은 이정표였으나 이제는 쓸모가 없다는 사실을 깨닫게 될 것이다.
- 애벌레는 엄청난 양의 잎사귀를 먹도록 완벽히 설계됐다. 하지만 애벌레는 짝을 찾을 수 없다. 애벌레는 짝을 찾기 위한 비행을 설계하기 전에 먼저 나비로 스스로를 리팩토링 해야 한다.
- 시스템이 어때야 하고, 어떻지 말아야하는지에 대한 관념을 버리고 우리 앞에 나타난 새로운 설계를 볼 수 있도록 노력해보자.
단위 테스트 만들기 (Create a Unit Test)
- 코드를 작성하기 전에 테스트를 먼저 작성하면, 코드를 작성하는 것이 훨씬 쉽고 빨라진다는 것을 알게 될 것이다.
- 단위 테스트를 만들고 테스트를 통과하는 코드를 작성하는 시간을 합치면 바로 코드 작업을 한 시간과 거의 같다.
- 하지만 이미 단위 테스트들이 있는 경우 코드 작업 이후 테스트를 만들 필요가 없으며 이는 당장은 약간의 시간, 향후에는 엄청난 시간을 절약시켜 줄 것이다.
- 단위 테스트를 만드는 것은 개발자가 어떤 작업을 해야하는가 고민하는 것을 도와준다.
- 요구 사항은 테스트들을 통해서 선명해진다.
- 실행가능한 코드의 형태로 쓰여진 스펙에는 오해의 여지가 없다.
- 우리는 작업하는 동안 즉각적인 피드백을 받는다.
- 개발자가 필요한 기능을 모두 개발하고 난 뒤에도 선명하지 않을 때가 종종 있다.
- 확장성과 에어의 조건들을 생각하다 보면 Scope Creep(범위의 변동)이 일어날 수 있다.
- 만약 우리가 단위 테스트를 먼저 작성한다면 우리가 언제 작업이 완료되는지 알 수 있다. (모든 테스트가 통과할 때!)
- 시스템 설계에도 이점이 있다.
- 어떤 소프트웨어 시스템은 단위 테스트가 매우 어렵다.
- 이러한 시스템들은 전형적으로 전혀 다른 팀들에 의해 코딩이 먼저 이루어지고 그 다음 테스트가 작성된 것이다.
- 테스트를 먼저 작성함으로써, 고객에게 전달될 모든 가치들을 시험해보고자 하는 욕구만큼 우리의 설계가 영향을 받을 것이다.
- 우리의 설계는 보다 테스트하기 쉬워지는 방향으로 이 사실을 반영할 것이다.
- 소프트웨어의 단위 테스트를 먼저 작성하는 데에는 리듬이 있다.
- 당면한 문제의 작은 부분부터 정의하기 위해 테스트를 하나 작성한다. 그리고 그 테스트를 통과하는 간단한 코드를 작성한다.
- 그 다음 두번째 테스트를 작성한다. 이제 새로운 테스트를 통과하는 코드를 추가한다.
- 더 이상 테스트가 남아있지 않을 때까지 계속한다.
- 우리가 작성할 코드는 간단하고 간결하며 우리가 원하는 기능만 구현할 것이다.
- 다른 개발자들은 테스트를 검색하며 이 새로운 코드의 사용법을 익힐 수 있다.
- 정의되지 않은 결과를 내는 인풋은 테스트 suite에서 거의 찾아보기 힘들 것이다.
지속적 통합 (Continuous Integration)
- 개발자는 가능한 한, 몇 시간에 한 번씩 코드 저장소에 코드를 커밋하고 통합해야 한다.
- 어떤 경우에도 하루 이상 변경된 코드를 가지고 있지 말자.
- 지속적 통합은 개발자들이 재사용 가능한 코드 또는 공유 가능한 코드에 대해 서로 소통하지 않을 경우 발생할 수 있는 개발 공수의 분기, 파편화를 방지할 수 있다.
- 모두는 최신 버전을 가지고 작업해야한다.
- 사용되지 않는 코드를 변경하여 통합 브랜치의 head를 아프게 해선 안 된다. (골치 아픈 것과 중의적 표현인듯)
- 각 개발 페어들은 그들의 코드가 합리적인 충돌을 가져올 때 통합에 대한 책임이 있다.
- 이는 단위 테스트가 모두 100%로 통과하거나 계획된 기능의 작은 부분이 완료된 때일 것이다.
- 주어진 시간에 오직 한 페어의 개발자들이 통합 작업을 하고, 몇 시간의 코딩을 더 해낸다면 잠재적인 문제를 거의 없앨 수 있다.
- 지속적 통합은 호환성 문제를 일찍이 방지하거나 감지한다.
- 통합은 마치 "호미로 막을 것 가래로 막는" 류의 활동이다.
- 즉, 프로젝트에 걸쳐 조금만 통합하려고 한다면 프로젝트의 기한이 넘어갈 정도로 몇 주동안 전혀 통합 시도를 하지 않는 스스로를 발견할 수 있을 것이다.
- 항상 시스템의 최신 버전에서 작업을 할 수 있도록 하자.
- 기존의 사고나 목표에 대한 집착보다는 단순성과 직관성을 강조하는 활동, 기술 또는 주제에 대한 접근 [본문으로]