《敏捷开发修炼之道 高效程序员的45个习惯》

看完《敏捷开发修炼之道 高效程序员的45个习惯》，以下是摘抄的觉得还不错的一些建议。

1. 前期不要过分设计，设计个总体方向就好。比如不要设计到某个类有多少字段多少方法，应该设计该类的名称、职责和协作者。

2. 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力，而不是启发你的工作。

3. 敏捷方法可以快速地响应变化，它强调团队合作，人们专注于具体可行的目标（实现真正可以工作的软件），这就是敏捷的精神。

4. 在敏捷团队中，如果你向敏捷团队中的同事抱怨，他们会说：“好，我能帮你做些什么？”他们把精力直接放到解决问题上，而不是抱怨。他们的动机很明确，重点就是做事，不是为了自己的面子，也不是为了指责，也无意进行个人智力角斗。你必须把重点放在解决问题上，而不是去极力证明谁的主意更好。

5. 每个人都要时刻记住，我们的目标是让项目成功满足用户需求。客户并不关心这是谁的主意，他们关心的是，这个软件是否可以工作，并且是否符合他们的期望。结果最重要。

6. 在开发者眼中的最好，不一定就是用户认为最好的。反之亦然。

7. 不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。

8. 如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决办法，但代码仍然令人费解，唯一的解决办法是重构代码，让它可读性更强。如果你没有马上理解那段代码，不要轻易地否定和重写它们。那不是勇气，而是鲁莽。

9. 当你遇到艰难抉择的时候，固定的时间期限会促使你做决定。你不能在讨论或功能上浪费很多时间，这些时间可以用于具体的工作，时间盒会帮助你一直前进。

10. DTD: Document Type Definitions 文档类型定义

11. 询问用户，哪些是使产品可用且不可缺少的核心功能。不要为所有可能需要的华丽功能而分心，不要沉迷于你的想象，而去做那些华而不实的用户界面。

12. 只在有具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。

13. 在代码可以传递意图的地方不要使用注释。如方法：sendToHost()就不需要写这个方法是做什么的了。

14. 面对问题并解决它们是开发人员的一种生活方式。当问题发生时，我们希望赶紧把它解决掉。维护一个问题及其解决方案的日志（daylog）并且应该是便于以关键字搜索到的。

15. 将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。

16. 如果你一直就一个主题向不同的人反复阐述，不妨记录笔记，此后就此主题写一篇文章，甚至是一本书。

17. 给别人解决问题的机会，指给他们正确的方向，而不是直接提供解决方案，这样每个人都能从中学到不少东西。如果有人还是没有任何线索，那就给更多的提示吧（甚至是答案）；如果有人提出来某些想法，不妨帮他们分析每种想法的优劣之处；如果有人给出的答案或者解决方法更好，那就从中汲取经验，然后分享你的体会吧。作为指导者，应该鼓励、引领大家思考如何解决问题。

18. 对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务完成后复查代码。

19. 及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。

20. 例会在上班后半个小时到一个小时后开比较合适，让员工从上班路上缓过来，到公司后泡杯茶、处理一下邮件。开会后也有一段时间来处理会议讨论和工作的事才到中午吃饭时间。

21. “立会”在开会时，所有参与者都必须站着，到场的人依次回答以下三个问题：

　　（1）我昨天干了什么？

　　（2）我今天打算干什么？

　　（3）我遇到了什么问题？

22. 在你过去的工作中，遭遇过哪些印象深刻的困难，最后是怎么解决的？在我看来，与问题本身的难度相比，解决问题的方式、步骤以及反思的程度，才能体现出一个人的职业素养。

23. 如果你希望自己的软件灵活可变，那就应该时常修改她。

24. 不能铭记过去的人，注定要重蹈覆辙。

25. 当你讲完的时候不应该问别人懂了吗，应该问你知道我在讲什么吗？