[读书笔记—程序员]《高效程序员的45个习惯：敏捷开发修炼之道》- 苏帕拉马尼亚姆，亨特

虽然不记得阅读本书用了多久，但是整理本书的读书笔记用了两个小时的时间，因为本书的大部分内容对于笔者来说都是新知识,很难进行归纳总结

本书所讲的是程序员应具有的工作态度和在团队中作为开发者和领导者具备的各种”敏捷的”习惯。虽然本书对于程序员的硬实力（本书讲解的编程语言是面向对象类语言，但是讲解的代码非常少）帮助不大，但是对于程序员应该具备的软实力的培养和提高有极大的帮助，是每位程序员都应该反复阅读的书籍。

第一章 敏捷-高效软件开发之道

什么是敏捷开发方法？

2001年2月，17位志愿者（包括作者之一Andy在内）聚集在美国犹他州雪鸟度假胜地，讨论一个新的软件开发趋势，这个趋势被不严格地称为“轻量型软件开发过程”。
我们都见过了因为开发过程的冗余、笨重、繁杂而失败的项目。世上应该有一种更好的软件开发方法——只关注真正重要的事情，少关注那些占用大量时间而无甚裨益的不重要的事情。

这些志愿者们给这个方法学取名为敏捷。他们审视了这种新的软件开发方法，并且发布了敏捷开发宣言：一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。

敏捷的重点：

要求团队中的每一个人（包括与团队合作的人）都具备职业精神，并积极地期望项目能够获得成功。它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。

这意味着你不会在项目结束的时候才开始测试，不会在月底才进行一次系统集成，也不会在一开始编码的时候就停止收集需求和反馈。越早发现问题，就越容易修复问题，所以应该就在此时此刻把问题修复。

第二章 态度决定一切

1. 做事

在敏捷的团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是在指责犯错者上面纠缠。应该把精力放在解决问题上，而不是抱怨。

世上最糟糕的工作就是和一群爱搬弄是非的人共事。他们对解决问题并没有兴趣，相反，他们爱在别人背后议论是非。他们挖空心思指手画脚，议论谁应该受到指责。这样一个团队的生产力是极其低下的。如果你发现自己是在这样的团队中工作，不要从团队中走开——应该跑开。

一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作，应互相帮助，而不是互相指责。

2. 欲速则不达

拙劣的代码工人会这样不假思索地改完代码，然后快速转向下一个问题。
而优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须要加1，更重要的是，他会想明白会产生什么其他影响。

在工作压力之下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引发大问题。

所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。

3. 对事不对人

对事不对人，让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。

在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。

即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。用Les Brown的一句话说就是：“你不需要很出色才能起步，但是你必须起步才能变得很出色。

能容纳自己并不接受的想法，表明你的头脑足够有学识。－亚里士多德

设立仲裁人：
在会议的开始，选择一个仲裁人作为本次会议的决策者。每个人都要有机会针对问题畅所欲言。仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进行。仲裁人可以防止明星员工操纵会议，并及时打断假大空式发言。仲裁人应该专注于调停，而不是发表自己的观点（理想情况下不应在整个项目中有既得利益）。

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

4. 排除万难，奋勇前进

也许你会跳起来告诉周围的人，那些代码是多么糟糕，但那只是抱怨和发泄，并不能解决问题。相反，你应该重写这些代码，并比较重写前后的优缺点。动手证明（不要只是嚷嚷）最有效的方式，是把糟糕的代码放到一边，立刻重写。列出重写的理由，会有助于你的老板（以及同事）认清当前形势，帮助他们得到正确的解决方案。

你应深知怎样做才是正确的，或者至少知道目前的做法是错误的。要有勇气向其他的项目成员、老板或者客户解释你的不同观点。

第三章 学无止境

即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。
——Will Rogers（美国著名演员）

5. 跟踪变化

唯有变化是永恒的-赫拉克利特

跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

如何才能跟上技术变化的步伐呢？

• 迭代和增量式的学习。每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。记下那些你想学习的东西——当你听到一些不熟悉的术语或者短语时，简要地把它记录下来。然后在计划的时间中深入研究它。

• 了解最新行情。互联网上有大量关于学习新技术的资源。阅读社区讨论和邮件列表，可以了解其他人遇到的问题，以及他们发现的很酷的解决方案。选择一些公认的优秀技术博客，经常去读一读，以了解那些顶尖的博客作者们正在关注什么。

• 参加本地的用户组活动。

• 参加研讨会议。计算机大会在世界各地举行，许多知名的顾问或作者主持研讨会或者课程。这些聚会是向专家学习的最直接的好机会。

• 如饥似渴地阅读。找一些关于软件开发和非技术主题的好书，也可以是一些专业的期刊和商业杂志，甚至是一些大众媒体新闻。

6. 对团队投资

“在一个团队中，如果只是你个人技术很好还远远不够。如果其他团队成员的知识不够，团队也无法发挥其应有的作用：一个学习型的团队才是较好的团队。

比如你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。

“午餐会议”是在团队中分享知识非常好的方式。在一周之中挑选一天，例如星期三（一般来说任何一天都可以，但最好不要是星期一和星期五）。事先计划午餐时聚集在一起，这样就不会担心和其他会议冲突，也不需要特别的申请。为了降低成本，就让大家自带午餐。

优秀的管理者会重用那些能提高其他团队成员价值的人，因此这些活动也直接有助于你的职业生涯。

7. 懂得丢弃

在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。

学习一门新的编程语言时，应使用推荐的集成开发环境，而不是你过去开发时用的工具插件。

新技术会让人感到有一点恐惧。你确实需要学习很多东西。已有的技能和习惯为你打下了很好的基础，但不能依赖它们。

8. 打破沙锅问到底

为了解决问题，你需要知道许多可能的影响因素。当找人询问任何相关的问题时，让他们耐心地回答你的问题，这是你的职责。

或者，假设你和资深的开发者一起工作。他们可能比你更了解这个系统。但他们也是人，有时他们也会忘记一些东西。你的问题甚至会帮助他们理清思路。你从一个新人角度提出的问题，给他们提供了一个新的视角，也许就帮助他们解决了一直令人困扰的问题。

不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。

这就好比是从矿石中采掘贵重的珠宝。你不停地筛选掉无关的物质，一次比一次深入，直到找到发光的宝石。你要能感觉到真正地理解了问题，而不是只知道表面的症状。

9. 把握开发的节奏

在许多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律。那样的随机安排很难处理。你根本不知道明天将会发生什么，也不知道什么时候开始下一轮的全体“消防演习”。

你可以做到在每天下班离开公司前运行测试，并提交一天完成的代码。

许多的敏捷技巧来源于时间盒——设定一个短时的期限，为任务设定不能延长的最终期限。你可以选择放弃其他方面的任务，但是最终期限是不变的。你可能不知道完成所有的任务需要多少个时间盒，但每个时间盒必须是短期的、有限的，并且要完成具体的目标。

“项目开发需要有一致和稳定的节奏。编辑，运行测试，代码复审，一致的迭代，然后发布。如果知道什么时候开始下一个节拍，跳舞就会更加容易。

第4章　交付用户想要的软件

我们的敌人不是客户，不是用户，不是队友，也不是管理者。真正的敌人是变化。软件开发如战争，形势的变化快速而又剧烈。固守昨天的计划而无视环境的变化会带来灾难。你不可能“战胜”变化——无论它是设计、架构还是你对需求的理解。

敏捷:成功的软件开发方法——取决于你识别和适应变化的能力。只有这样才有可能在预算之内及时完成开发，创建真正符合用户需求的系统。

10. 让客户做决定

在设计方面，做决定的时候必须有开发者参与。可是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。

开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。

当你和客户讨论问题的时候，准备好几种可选择的方案。不是从技术的角度，而是从业