0、注明
本文内容摘选自《高效程序员的10个习惯（中文精选版）Practice agile developer-InfoQ》，文档内容稍加整理与总结而成。
1、作者
Venkat Subramania 等
2、节选
《高效程序员的45个习惯敏捷开发修炼之道》
3、软件开发之内功修炼口诀
迭代开发，价值优先；
分解任务，真实进度；
站立会议，交流畅通；
用户参与，调整方向；
结对编程，代码质量；
测试驱动，安全可靠；
持续集成，尽早反馈；
自动部署，一键安装；
定期回顾，持续改进；
不断学习，提高能力。
4、习惯1：对事不对人
4.1、对待一个人出现明显错误有哪些常见的反应
（1）否定个人能力；
===》坚决不可取，杀敌一千，自损八百
- 指出明显的缺点，并否定其观点；
===》观点虽正确，但表达不妥当；
- 询问你的同事，并提出你的顾虑
===》正确的表达方式
Q1:现实中你会选择哪一个？注意第一意识里的选择是什么。
INFO1：引导性地提出一个问题或疑问，从而让对方自己意识到问题的存在是一个不错的技巧。
INFO2：要专业而不是自我。
INFO3：把重点放在解决问题上，而不是极力证明谁的主意更好。
INFO4：团队中的每个人都有自由表达观点的权利（观点对与错不是重点，重点是表达观点）。
INFO5:你不需要很出色才能起步，但是你必须起步才能变得更出色。
INFO6：能容纳自己不能接受的想法，说明你足够有学识。----亚里士多德
4.2、一些有效的特殊“招式”
1、设定最终期限
没有最好的答案，只有更合适的答案。
2、逆向思维
判断一个方案的优缺点时少带一点个人情感。
3、设立仲裁人
会议开始时，选择一个仲裁人作为本次会议的决策者。
4、支持已经做出的决定
5、习惯2：跟踪变化
5.1、唯有变化是永恒的。
5.2、如何跟上技术变化的几个建议
1、迭代和增量式学习
每天学习一点新知识，时间不需要很长，贵在坚持。
2、了解最新行情
3、参加本地用户组活动
4、尽可能的参加研讨会议
5、如饥似渴的阅读
6、你不需要精通所有技术（也不太可能），但需要知道行业的动向，从而规划你的职业生涯。
6、习惯3：让设计指导而不是操纵开发
INFO1：好的设计应该是正确的，而不是精确的。它是目标，不是具体的处方。
INFO2:不要在前期做大量的设计。
INFO3:白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会分散你的精力，而不是启发你的工作。
7、习惯4：提早实现自动化部署
INFO 1:一开始就进行全面的部署，而不是等到项目的尾期。
INFO 2:系统的安装或部署应该简单、可靠及可重复。
INFO 3:在没有询问及征得用户同意前，安装程序绝对不能删除用户数据。
8、习惯5：度量真实进度
INFO 1:判断工作进度最好看实际花费的时间而不是估计的时间。
INFO2:诚实非常重要，隐瞒真相毫无意义。
INFO3:清楚项目的真实进度，是一项强大的技术。
INFO4:Scrum方法中的sprint
9、习惯6：用代码沟通
INFO 1:DRY原则，Don’t Repeater Yourself。
INFO 2:不要用注释包括你的代码。
Don’t comment to cover your code.
INFO 3:通过名称来进行魔法控制，是文学和神话中一种常用的主题，在软件开发中也是如此。
INFO 4:代码能够自解释而不用依赖注释是一件美好的事情。
INFO 5:解释代码做了什么的注释用处不大，相反，注释应该说明为什么这样写代码。
INFO 6:当重写方法时，保留描述原有方法意图和约束的注释。
10、习惯7：编写高内聚的代码
INFO 1：内聚性用来评估一个组件（包、模块或配件）中成员的功能相关性。内聚程度高，
表明各个成员共同完成了一个功能特性或是一组功能特性。内聚程度低的话，表
明各个成员提供的功能是互不相干的。
INFO 2:类也要遵循内聚性。如果一个类的方法和属性共同完成了一个功能（或是一系列
紧密相关的功能），这个类就是内聚的。
INFO 3:让类的功能尽量集中，让组件尽量小。
INFO 4: 有可能会把一些东西拆分成很多微小的部分，而使其失去了实用价值。当你需
要一只袜子的时候，一盒棉线不能带给你任何帮助。
11、习惯8：根据契约进行替换
INFO 1:任何继承后得到的派生类对象，必须可以替换
任何被使用的基类对象，而且使用者不必知道任何差异。换句话说，某段代码如
果使用了基类中的方法，就必须能够使用派生类的对象，并且自己不必进行任何
修改。
INFO 2:针对is-a关系使用继承；针对has-a或uses-a关系使用委托。
INFO 3:那么继承和委托分别在什么时候使用呢？
（1）如果新类可以替换已有的类，并且它们之间的关系可以通过is-a来描述，就要
使用继承。
（2） 如果新类只是使用已有的类，并且两者之间的关系可以描述为has-a或是uses-a，
就使用委托吧。
INFO 4:相对继承来说，委托更加灵活，适应力也更强。
12、习惯9：报告所有的异常
INFO 1:从事任何编程工作，都要考虑事物正常状况下是如何运作的。不过更应该想一想，
当出现问题——也就是事情没有按计划进行时，会发生什么。
INFO 2:处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样
做也不行。在写代码时要估计到会发生的问题。
INFO 3: 决定由谁来负责处理异常是设计工作的一部分。
INFO 4:不是所有的问题都应该抛出异常。
13、习惯10：做代码复查
INFO 1:用户是最好的测试人员。
INFO 2:代码复查和缺陷移除
要寻找深藏不露的程序bug，正式地进行代码检查，其效果是任何已知形式测
试的两倍，而且是移除80%缺陷的唯一已知方法。
——Capers Jones的《估算软件成本》
INFO 3:代码复查最基本的检查列表
（1）代码能否被读懂和理解？
（2） 是否有任何明显的错误？
（3） 代码是否会对应用的其他部分产生不良影响？
（4） 是否存在重复的代码（在复查的这部分代码中，或是在系统的其他部分代码）？
（5） 是否存在可以改进或重构的部分？
INFO 4:对于提升代码质量和降低错误率来说，代码复查是无价之宝。
INFO 5:不进行思考、类似于橡皮图章一样的代码复查没有任何价值。
INFO 6: 同样的功能，不同开发人员的代码实现可能不同。差异并不意味着不好。除非
你可以让某段代码明确变得更好，否则不要随意批评别人的代码。
INFO 7: 要确保代码复查参与人员得到每次复查活动的反馈。作为结果，要让每个人知
道复查完成后所采取的行动。