学习笔记之--高效程序员的45个习惯

有本关于敏捷开发方面的书非常不错《高效程序员的45个习惯-敏捷开发修炼之道》，Venkat Subramaniam和Andy Hunt著，该书简短、易读、精炼、深入，深刻且实用。对于想要采用敏捷方法的人很有价值。此书通过常理和经验，阐述了为什么应该在项目中实用敏捷方法。更难得的是，这些行之有效的实战经验，竟然从一本书中得到了。如果能拿这些习惯在项目中一以贯之，肯定会受益匪浅。下本罗列该书这45个习惯，一并列出其中的Key Point.

--------------------------------------------------------------------------------------------

>>> 态度决定一切 <<<

【习惯01】做事

• 问题出来了，重点放在解决问题上，而不是在指责犯错者上纠缠。
• 动机要明确，重点是做事，不是为了自己的面子，也不是为了指责，也无意个人智力决斗。 
• 过程符合标准并不意味着结果是正确的。敏捷团队重结果胜于重过程。 
• 指责不会修改bug.把矛头对准解决问题的办法，而不是人。这是真正有用处的正面效应。
• 一个重大的错误应该被当是一次学习而不是指责他人的机会。团队应该互帮互助，而不是指责。

【习惯02】欲速则不达

• 千里之堤毁于蚁穴，大灾难是逐步演化来的。一次又一次快速修复每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
• 在工作压力下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只能解决表面问题，最终会引发大问题。
• 重构代码之前必须彻底理解它，否则就不能进行有效的改变！ 
• 实行代码复审，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。
• 不要坠入快速的简单修复之中。要投入时间和精力来保持代码的整洁、敞亮。

【习惯03】对事不对人

• 面对一个明显的错误最好的反应:询问你的队友并提出你的顾虑。--没有谴责，没有评判，只是简单的表达自己的观点。整个团队要关注真正有价值的问题，而不是勾心斗角，误入歧途。
• 好的软件产品和好的软件设计，都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点，远远胜于单个想法为项目。带来的价值。负面的评论和态度会扼杀创新。 
• 把问题重点放在解决问题上，而不是去极力证明谁的主意更好。  
• 经常提出自己的观点和建议，记住，任何一个专家都是这么开始的。你不需要很出色才起步，但必须起步才能变得很出色
• 让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。

【习惯04】排除万难，奋勇前进

• 有时，绝妙的计划会因为勇气不足而最终失败。尽管前方很危险，你必须有勇气向前冲锋，做你认为对的事情。
• 践行良好的习惯。 
• 做正确的事。要诚实，要有勇气去说出实情。有时,这样做很困难，所以我们要有足够勇气。
• 有时候勇气是扫除障碍的唯一途径，否则问题会一直恶化下去。鼓起勇气从克服恐惧开始。
• 如果没有理解那段代码，不要轻易地否定和重写它们。那不是勇气，而是鲁莽。

--------------------------------------------------------------------------------------------

>>> 学无止境 <<<

【习惯05】跟踪变化

• 唯有变化是永恒的
• 迭代和增量式的学习
• 了解最新的行情
• 参加本地的用户组活动
• 参加研讨会议
• 如饥如渴地阅读
• 不需要精通所有的技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
• 你不可能精通每一项技术，也没有必要这样做。
• 只要你在某些方面成为专家，就能使用同样的方法，很容易成为新领域的专家。

【习惯06】对团队投资

• 一个学习型的团队才是较好的团队
• 午餐会议是在团队中分享知识非常好的方式。
• 总是要成为你所在的团队中最差的一位。这样才有动力超越他们。
• 坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的会议非敏捷也。
• 通过午餐会议可以增进每个人的知识和技能，并能帮助大家聚集在一起进行沟通交流。 

【习惯07】懂得丢弃

• 敏捷的根本之一就是拥抱变化。既然变化是永恒的，你有可能一直使用相同的技术和工具吗?
• 相比而言，开发者的时间才是紧缺和昂贵的资源。
• 需要耗费10人年开发的J2EE项目已经从辉煌走向下坡路。PHP,Ruby on Rails这样的框架越来越受到关注。
• 只有更少被旧习惯牵绊，才容易养成新习惯。
• 学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。
• 毕竟汽车要比马车车厢强得多。 

【习惯08】打破砂锅问到底

• 在理解一个问题的时候，需要渐次地问5个以上的为什么。
• 不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
• 好比是从矿石中采掘贵重的珠宝。要不停的筛选无关的物质，一次比一次深入，直到找到发光的宝石。
• 你要能感觉到真正地理解了问题，而不是只直到表面的症状。
• 在提问之前，想好你提问的理由，这会有助于你问出恰当的问题。

【习惯09】把握开发节奏

• 要养成这样的习惯，在那时就准备好一切参加站立会议。
• 不管你的一个迭代是多长，都应该坚持--确保每个迭代周期的时间相同很重要。
• 解决任务在事情变得一团糟之前。保持事件稳定重复的间隔，更容易解决常见的重复任务。
• 项目开发需要有一致和稳定的节奏。如果知道什么时候开始下一个节拍，跳舞就会更加容易。

--------------------------------------------------------------------------------------------

>>> 交付用户想要的软件 <<<

【习惯10】让客户做决定 

• 在设计方面，做决定的时候必须有开发者参与。
• 开发者能做的一个最重要的决定就是:判断哪些是自己决定不了的，应该让企业主做决定。
• 让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。
• 用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
• 业务应用需要开发者和业务负责人相互配合来开发。

【习惯11】让设计指导而不是操纵开发

• 设计是软件开发过程不可缺少的步骤。
• 设计满足实现即可，不必过于详细。
• 做到精确，如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。
• 战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。那是战术设计的任务。
• 不要一开始就进行战术设计，它的重点是集中在单个的方法或数据类型上。
• 这时，更适合讨论如何设计类的指责。因为这仍然是一个高层次、面向目标的设计。
• 好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。
• 你不要被设计操纵。
• 好的设计应该是正确的，而不是精确的。
• 计划是没有价值的，但计划的过程是必不可少的。

【习惯12】合理地使用技术

• 盲目地为项目选择技术框架，就好比是为了少交税而生孩子。
• 代码写的越少，需要维护的东西就越少。
• 不要开发你能下载到的东西。
• 要考虑:这个技术框架真能解决这个问题吗? 你将会被它栓住吗? 维护成本是多少。
• 根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。
• 对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。

【习惯13】保持可以发布

• 任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
• 已提交的代码应该随时可以行动。
• 简单流程。在本地进行测试->检出最新的代码->提交代码.
• 最好的办法，应该有一个持续集成系统，可以自动集成并报告集成结果。
• 保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署

【习惯14】提早集成，频繁集成

• 敏捷的一个主要特点就是持续开发。
• 你能一边进行集成，一边进行独立开发。使用mock对象，编写独立的单元测试，而不需要立刻就集成和测试。
• 绝不需要做大瀑布式的集成
• 代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
• 成功的集成就意味着所有的单元测试不停地通过。

【习惯15】提早实现自动化部署

• 质量保证人员应该测试部署过程。
• 如果现在还是手工帮助质量保证人员安装应用，花一些时间，考虑如何将安装过程自动化。
• 一开始就进行全面部署，而不是等项目的后期，这会有很多好处。
• 使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试以来的关系。
• 质量保证人员要像测试应用一样测试部署。

【习惯16】使用演示获得频繁反馈

• 需求就像是流动着的油墨
• 应该定期地，每隔一段时间，比如说一个迭代，就与客户会晤，并且演示你已经完成的功能特性。
• 要频繁地获得反馈
• 清晰可见的开发。在开发的时候，要保持应用可见。
• 每隔一周或两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
• 演示是用来让客户提出反馈的，有助于驾驭项目的方向。

【习惯17】使用短迭代，增量开发

• 统一过程和敏捷方法都使用迭代和增量开发。
• 迭代开发是，在小而重复的周期里完成各种开发任务:分析、设计、实现、测试和获得反馈，所以叫迭代。
• 给我一份详细的长期计划，我就会给你一个注定完蛋的项目。
• 对付大项目，最理想的办法就是小步前进，这也是明捷方法的核心。
• 发布带有最小却可用功能块的产品。每个增量开发中，使用1`4周左右迭代周期。
• 短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。
• 严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。

【习惯18】固定的价格就意味着背叛承诺

• 固定的价格就是保证要背叛承诺。
• 基于真实工作的评估。
• 让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
• 如果你对答案不满意，那么看看你是否可以改变问题。
• 如果你现在别无选择，你不得不提供一个固定的价格，那么你需要学到真正好的评估技巧。

--------------------------------------------------------------------------------------------

>>> 敏捷反馈 <<<

【习惯19】守护天使

• 敏捷就是管理变化的，而且，代码可能是变化最频繁的东西。
• 编写能产生反馈的代码。
• 确保测试是可以重复的。
• 测试你的边界条件。
• 不要放过任何一个失败的测试。
• 使用自动化的测试。好的单元测试能够为你的代码问题提供及时的警报。
• 如果没有到位的单元测试，不要进行任何设计和代码修改。
• 单元测试时优质股，值得投资。
• 人们不编写单元测试的很多借口是因为代码中的设计缺陷。
• 单元测试只有在达到一定测试覆盖率的时候，才能真正地发挥作用。

【习惯20】先用它再实现它

• 编码之前，先写测试。
• 先写测试，你就会站在代码用户的角度去思考，而不仅仅是一个单纯的实现者。
• 先写测试有助于消除过度复杂的设计，让你可以专注于真正需要完成的工作。
• 一些不必要的过于复杂的事情，测试优先会帮助我们，防止我们走偏。
• 好的设计并不意味着需要更多的类。
• TDD有机会让你编写之前，可以深思熟虑将如何用它。
• 这会迫使你去思考它的可用性和便利性，并让你的设计更加注重实效。
• 将TDD作为设计工具，它会为你带来更简单更有实效的设计。
• 这种感觉就是，只有在具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。 

【习惯21】不同环境，就有不同问题

【习惯22】自动验收测试

【习惯23】度量真实的进度

 

【习惯24】倾听用户的声音

--------------------------------------------------------------------------------------------

>>> 敏捷编码 <<<

【习惯25】代码要清晰地表达意图

【习惯26】用代码沟通

【习惯27】动态评估取舍

【习惯28】增量式编程

【习惯29】保持简单

【习惯30】编写内聚的代码

【习惯31】告知，不要询问

【习惯32】根据契约进行替换

--------------------------------------------------------------------------------------------

>>> 敏捷调试 <<<

【习惯33】记录解决问题的日志

【习惯34】警告就是错误

【习惯35】对问题各个击破

【习惯36】报告所有的异常

【习惯37】提供有用的错误信息

--------------------------------------------------------------------------------------------

>>> 敏捷协作 <<<

【习惯38】定期安排会面时间

【习惯39】架构师必须写代码

【习惯40】实行代码集体所有制

【习惯41】成为指导者

【习惯42】允许大家自己想办法

【习惯43】准备好后再共享代码

【习惯44】做代码复查

【习惯45】及时通报进展与问题