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