애자일 프랙티스 - Practices of an Agile Developer

위 제목의 책에서 발췌.
---

가장 어려운 것부터 시작하라.
항상 제일 어려운 문제부터 다루고, 맨 마지막에 쉬운 문제를 남겨라.

단위 테스트를 사용하라.

개인 감정을 드러내지 말고, 프로다운 자세를 유지하자.

개발팀의 좁은 범위 내에서의 사소한 공손함과 정중함은 오래도록 남아서, 팀이 개인 사이의 이해관계에 따라서 분열하지 않고 순수하게 아이디어의 장점에만 계속해서 집중하게 한다.

의견을 말하지 못하게 하는 분위기야말로 진짜 문제다.

레스 브라운(Les Brown), "시작하기 위해 위대할 필요는 없다. 다만 위대해지기 위해 시작해야 한다."

[변화에 뒤처지지 말라]

반복해서 조금씩 배우자
신기술을 위해 매일 일정 시간을 확보하자. 공부 시간이 길 필요는 없지만, 규칙적이어야 한다.

최신 소식을 얻자
포럼, 메일링 리스트 구독, technical issue들을 다루는 블로그를 찾아서 읽기.
pragmaticprogrammear.com

기술 변화를 따라 가라
모든 분야에서 전문가가 될 필요는 없지만, 업계가 어디로 가는지 알고 있어야 하고, 그에 맞춰서 경력과 프로젝트 계획을 세워야 한다.

모든 것에 전문가가 될 수는 없다. 그렇게 되려고 하지도 말라. 하지만 일단 몇 가지 분야에서 전문가가 되면 선택한 새 분야에서 전문 지식을 얻는 것이 쉬워진다.

[팀에 투자하라]

지식 공유.
팀 내로 회의를 한정하도록 한다.
규칙적인 일정을 지켜라.

[설계가 강요하는 대신 안내하도록 하라]

프로젝트 기간동안 문서화된 상세 설계를 최신으로 유지하는 일은 별로 소득도 없으면서 엄청나게 할 일이 많고 투자도 크다.

전략적 설계 vs. 전술적 설계

화이트 보드, 스케치북, 포스트잇 등은 훌륭한 설계 도구다. 복잡한 모델링 도구는 더 잘 파악하게 하기보다 오히려 괴롭히는 경향이 있다.

다운로드해 얻을 수 있는 프로그램을 새로 만들지 말라.

고객과 자주 접촉하고 매주 또는 2주마다 데모를 보이고 피드백을 미리 구하라.

얼마나 많은 일이 남았는지 측정하라
현실성이 떨어지는 측정 기준으로 자신이나 팀을 기만하지 말자. 해야 할 작업의 백로그를 측정하자.

[사용자에게 귀를 기울이라]

모든 불평은 진실을 담고 있다.
진실을 찾아, 진짜 문제를 해결해라.

Sanity check (test)는 개발자가 테스트 주체로서 테스트 케이스 없이 주요한 단위 모듈이나 시스템 모듈을 테스트 하는 기법을 말한다. Smoke Test와 자주 혼동해서 사용하는데, smoke test는 스크립트를 사용하는 반면에 sanity test는 스크립트 없이 적용된다.

[의도적이고, 의미 있게 프로그램 하라]

호어 온 소프트웨어 디자인 (Hoare on Software Design)
- C.A.R. 호어 (Charles Antony Richard Hoare)
소프트웨어 설게를 하는 두 가지 방법이 있다. 하나는 명백하게 어떤 결함도 없이 무척 간결하게 만드는 것이고, 다른 방법은 매우 복잡하게 만들어서 결함을 명백하게 찾지 못하게 만드는 것이다.

코드를 개발할 때, 항상 편리함보다는 읽기 쉬움을 선택해야 한다. 코드는 작성하는 것보다 훨씬 더 많이 읽히기 때문이다.

[경고는 진짜 에러다]

[아키텍트는 코드를 작성해야 한다]
좋은 설계자는 소매를 걷어 올리고 손을 더럽히며 주저없이 코딩을 할 수 있는 사람이다. 참된 아키텍트는 코드에 관여하지 못한다면 강력하게 항의 할 것이다.

좋은 디자인은 활동적인 프로그래머로부터 진화한다.
진짜 통찰력은 활동적인 코딩 작업에서 나온다. 코드를 작성하지 않는 아키텍트를 기용하지 말자. 시스템의 현실을 알지 못하는 아키텍트는 설계를 할 수 없다.

하지만, 아키텍트는 코딩을 위해서 충분한 시간을 쓸 수 없을 경우가 많으니, 가장 큰 코드 뭉치의 ciritical path에 두어서는 안된다.

[멘토가 되자]
아는 것을 공유하는 데 즐거움이 있다. 얻은 만큼 베풀어라. 더 나은 목표를 달성하기 위해서 다른 사람을 자극하자. 팀의 전체적인 역량을 향상시키자.

팀내의 공유에 멈추지 말고, 개인적인 블로그를 시작해서, 코드나 코드 관련 기술에 관한 글을 올리자. 대단히 엄청난 글이 아니어도 좋다. 남에겐 유용할 것이다.

자주 project restrospective 시간을 갖자. (각 iteration별로)
팀에서 피드백을 받자. 무엇을 잘 했고, 무엇을 조정해야 하고, 어떤 일이 잘 되지 않았는지 말이다.