====== 애자일 프로그래밍을 위한 개발자 실천 가이드 ======

[[book:292|애자일 프랙티스]] 에 나온 애자일 프로그래밍을 위한 45 가지 수칙을 정리했다.
====== 비난은 버그를 수정하지 못한다 ======
손가락질 하는 대신, 가능한 해결책을 제시하라. 중요한 것은 긍정적인 결과다.
====== 땜질식 수정에 빠지지 말라 ======
깔끔하고 모든 것이 드러나도록 코드에 정력을 쏟아라.
====== 사람이 아니라 아이디어를 비평하라 ======
누구 아이디어가 더 나은지를 입증하는 것이 아니라 해결책에 도달하는 데 자부심을 가져라.
====== 올바른 일을 하라 ======
정직하라. 그리고 진실을 얘기할 용기를 가져라. 때로 이렇게 한다는 것이 어려울 수도 있지만, 그렇기 때문에 용기가 필요한 것이다.
====== 기술 변화를 따라가라 ======
모든 분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고, 그에 맞춰서 경력과 프로젝트 계획을 세워야 한다. 
====== 여러분 자신과 팀에 대한 기대치를 높여라 ======
도시락 회의를 통하여 모든 사람의 지식과 숙련도를 올리고 사람들이 화합하게 하자. 즉 팀이 흥미를 보이는 기술이나 프로젝트를 이롭게 할 기술을 도입하자.
====== 새로운 기술을 배우고 예전 기술은 버려라 ======
새 기술을 배울 때, 여러분을 방해할 낡은 습관을 버려라. 결국 구형 차보다는 새 차가 훨씬 낫다.
====== 계속 왜냐고 물어봐라 ======
여러분이 들은 얘기들을 액면 그대로 받아들이지 마라. 쟁점이 되는 내용의 핵심을 이해할 때까지 계속 질문하라.
====== 일이 쌓이기 전에 부딪쳐라 ======
사건들 사이에 꾸준하고 반복적인 간격을 유지해야 일상적으로 되풀이되는 일을 해결하기 쉽다. 
====== 고객이 결정하도록 하라 ======
개발자, 관리자, 비즈니스 애널리스트가 비즈니스에 치명적인 결정을 내려서는 안된다. 사업주가 이해할 수 있는 언어로 세부 내용을 설명하고 사업주가 결정하도록 하라.
====== 좋은 설계는 지도다. 스스로 진화하게 하자 ======
설계는 바른 방향으로 인도한다. 그것은 허물 수 없는 경계가 아니다. 특정한 방식을 강요해서는 안된다. 여러분이 설계(혹은 설계자)에게 인질로 잡혀서는 안된다. 
====== 필요에 따라 기술을 택하라 ======
먼저 무엇이 필요한지 정하라. 그러고 나서 그 특정한 문제에 기술 사용 여부를 판단하라. 어떤 기술의 사용에 결정적인 질문을 하고 진실하게 답해보라.
====== 프로젝트를 항상 릴리스 가능하게 하라 ======
프로젝트를 항상 컴파일할 수 있고, 실행할 수 있으며, 테스트하고 당장에 배치할 수 있게 하자.
====== 일찍, 자주 통합하라 ======
코드 통합은 주요 위험 요인이다. 이 위험을 완화시키려면, 일찍 통합하고 규칙적으로 계속 통합해야 한다.
====== 시작부터 애플리케이션을 자동 배치하라 ======
의존성 테스트를 위해 다양한 구성의 머신에 애플리케이션을 설치할 때, 이 자동 배치를 사용하라. 품질보증은 애플리케이션 뿐 아니라 배치를 테스트해야 한다.
====== 분명히 보이게 개발하라 ======
애플리케이션이 개발 도중 항상 눈에 띄게 하고 고객의 마음에 들게 하라. 고객과 접촉하고 매 주 또는 2주에 한 번씩 데모를 사용하여 피드백을 미리 구하라.
====== 점진적으로 개발하라 ======
최소의 유용한 기능 단위로 묶어서 제품을 릴리스하라. 각 추가기능의 개발에 1~4 주 정도의 반복주기를 사용하라.
====== 실제 일을 기초로 해서 견적하라 ======
실질적인 견적을 내기 위해 팀이 현재 프로젝트를 고객과 함께 수행하도록 하라. 고객이 기능과 예산을 조절하도록 하라.
====== 자동화된 단위 테스트를 사용하라 ======
좋은 단위 테스트는 문제를 즉시 경고한다. 견고한 단위 테스트가 자리 잡지 않았다면 설계나 코드 변경을 하지 말자.
====== 만들기 전에 사용하라 ======
테스트 주도 개발을 설계 툴로써 사용하자. 테스트 주도 개발은 여러분을 더 실용적이고 더 간단한 설계로 인도할 것이다.
====== 차이는 다른 결과를 만든다 ======
지속적 통합 툴을 사용해서, 지원하는 플랫폼과 환경의 조합마다 단위테스트를 실행하자. 문제가 여러분을 부르기 전에 능동적으로 문제를 찾자.
====== 핵심 비즈니스 로직에 해당하는 테스트를 만들자 ======
고객이 이러한 테스트를 격리해서 검증하게 하고, 일반적인 테스트 수행의 일부로 이러한 테스트를 자동적으로 시험하게 하자.
====== 얼마나 많은 일이 남았는지 측정하라 ======
현실성이 떨어지는 측정 기준으로 자신이나 팀을 기만하지 말자. 해야 할 작업의 백로그를 측정하자.
====== 모든 불평은 진실을 담고 있다 ======
진실을 찾아, 진짜 문제를 해결하라.
====== 독창적이지 않고, 명확하게 코드를 작성하자 ======
코드를 읽는 사람에게 의도를 명확하게 표현하자. 읽기 쉽지 않은 코드는 독창적이지도 않다. 
====== 이야기하는 주석 ======
잘 고르고, 의미 있는 이름을 사용해서 코드를 문서화해라. 메서드의 목적과 제한 조건을 설명하는 주석을 사용하라. 좋은 코드를 대신하려고 주석을 사용하지 말자.
====== 능동적으로 트레이드 오프를 평가하자 ======
성능, 편의성, 생산성, 비용, 적시 릴리스를 고려하자. 성능이 적당하면, 다른 요소를 향상시키는 데 집중하자. 하찮거나 미미한 성능이나 우아함을 위해서 디자인을 복잡하게 하지 말자.
====== 짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자 ======
긴 주기 동안 코딩을 하는 것보다 짧은 주기에서 코딩을 하는 편이 더 낫다. 유지보수하는데 더 명확하고 간단하며 쉬운 코드를 만들 것이다.
====== 동작하는 가장 단순한 해결책을 만들자 ======
패턴, 원칙, 기술을 사용해야 하는 부득이한 사정이 있을 때만 패턴, 원칙, 기술을 포함하자.
====== 클래스에 집중하고 컴포넌트를 작게 유지하라 ======
커다란 클래스나 컴포넌트 혹은 다방면에서 잡다한 클래스를 만들고픈 유혹을 피하라.
====== 묻지 말고, 말해라 ======
다른 객체나, 컴포넌트의 일을 떠맡지 마라. 객체나 컴포넌트에 무엇을 하는지 알리고, 자신의 일에 충실하라.
====== 코드를 교체해서 시스템을 확장하자 ======
인터페이스 계약을 존중하는 클래스를 교체해서 기능을 추가하거나 강화하자. 위임은 언제나 상속보다 바람직하다. 
====== 문제와 해결책의 로그를 보존하자 ======
문제를 해결하는 일의 일부는 나중에 해결책을 찾고 적용할 수 있도록 해결책의 상세 내용을 보존하는 것이다. 
====== 경고를 에러처럼 다루자 ======
경고가 있는 코드를 체크인 하는 것은 에러가 있는 코드나 테스트에 실패한 코드를 체크인하는 것만큼 나쁘다. 체크인한 코드는 빌드 툴에서 어떤 에러도 만들어서는 안 된다. 
====== 문제를 격리해서 공격하라 ======
문제를 해결할 때 문제를 주위와 분리시켜라. 특히 큰 애플리케이션의 경우에 말이다.
====== 모든 예외를 처리하거나 전달하라 ======
예외를 덮어두지 말자. 임시로라도 말이다. 코드가 실패할 수 있다고 생각하며 작성하자.
====== 유용한 에러 메세지를 제공하자 ======
에러의 상세 내용을 알아내기 쉬운 방법을 제공하자. 문제가 생겼을 때 문제에 대해서 할 수 있는 한 많은 지원과 관련된 상세 정보를 제공하라. 그렇지만 이 정보와 함께 사용자를 파묻지는 말자.
====== 스탠드 업 미팅을 사용하자 ======
스탠드 업 미팅은 팀을 같은 곳에 둔다. 회의를 열성적이면서 짧고, 집중적으로 유지하자.
====== 좋은 디자인은 활동적인 프로그래머로부터 진화한다 ======
진짜 통찰력은 활동적인 코딩 작업에서 나온다. 코드를 작성하지 않는 아키텍트를 기용하지 말자. 시스템의 현실을 알지 못하는 아키텍트는 설계를 할 수 없다.
====== 코드 공동 소유를 강조하자 ======
개발자들을 순환시켜 전체 시스템의 다른 영역에 있는 서로 다른 모듈이나 태스크를 교차해서 개발시키자.
====== 멘토가 되자 ======
아는 것을 공유하는 데 즐거움이 있다. 얻은 만큼 베풀어라. 더 나은 목표를 달성하기 위해서 다른 사람을 자극하자. 팀의 전체적인 역량을 향상시키자.
====== 다른 사람에게 문제를 해결할 기회를 주자 ======
다른 사람에게 해결책을 주는 대신에 올바른 방향을 알려주자. 그 과정에서 모두 뭔가를 배울 수 있다.
====== 준비 되었을 때만 코드를 공유하라 ======
다른 사람이 쓸 수 있도록 준비되지 않은 코드는 절대 체크인하지 마라. 컴파일이 안 되었거나 단위테스트를 통과하지 못한 코드를 고의적으로 체크인 하는 것은 프로젝트의 범죄적인 태만 행위로 간주해야 한다.
====== 모든 코드를 리뷰하자 ======
코드 리뷰는 코드 품질을 개선하고 에러를 낮추는 데 매우 가치 있는 것이다. 코드 리뷰를 올바르게 했다면, 리뷰는 실용적이고 효과적일 수 있다. 다른 개발자롤 하여금 작업이 끝날 때마다 코드 리뷰를 하게 하자.
====== 다른 사람에게 계속해서 알리자 ======
여러분이 조사한 좋은 자료나 자신의 상황, 아이디어를 발표하자. 다른 사람이 일의 상황을 물을 때까지 기다리지 말자.


----
{{indexmenu>:#1|skipns=/^(wiki|etc|diary|playground)$/ skipfile=/^(todays|about|guestbook)$/ nsort rsort}}
----