《高效程序员的45个习惯》总结
一、敏捷——高效软件开发之道
- 敏捷的精神：它要求团队中的每一个人（包括与团队合作的人）都具备职业精神，并积极地期望项目能够获得成功。它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。
- 敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
二、态度决定一切
1、 做事
- 符合标准不是结果。敏捷团队重结果胜于重过程。
- 指责不能修复bug 。把矛头对准问题的解决办法，而不是人。
2、 欲速则不达
- 不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
- 不要急于修复一段没能真正理解的代码。这种 +1/-1 的病症始于无形，但是很快会让代码一团糟。要解决真正的问题，不要治标不治本。
- 所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
3、 对事不对人
- 我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。
- 脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太容易发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗？是否经常发生？
4、 排除万难，奋勇前进
- 做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
三、学无止境
5、 跟踪变化
- 跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
- 许多新想法从未变得羽翼丰满，成为有用的技术。即使是大型、热门和资金充裕的项目也会有同样的下场。你要正确把握自己投入的精力。
6、 对团队投资
- 你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。
- 坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。
7、 懂得丢弃
- 打破旧习惯很难，更难的是自己还没有意识到这个问题。丢弃的第一步，就是要意识到你还在使用过时的方法，这也是最难的部份。
8、 打破沙锅问到底
- 不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
- 你可能会跑题，问了一些与主题无关的问题，这样的问题是没有任何帮助的。要问到点子上。
9、 把握开发节奏
- 解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
- 在每天结束的时候，测试代码，提交代码，没有残留的代码。
四、交付用户想要的软件
10、 让客户做决定
- 让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
11、 让设计指导而不是操纵开发
- 一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
- 好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
- 即使初始的设计到后面不再管用，你仍需设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程必不可少。”在设计过程中学习是有价值的，但设计本身也许没有太大的用处。
12、 合理地使用技术
- 考虑引入新技术或框架之前，要先考虑几个方面：
- 这个技术框架真能解决这个问题吗？
- 你将会被它拴住吗？一些技术是贼船，一旦你使用了它，就会被它套牢，再也不可能回头了。
- 维护成本是多少？
- 每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或语言，一定要清楚它的利弊。
13、 保持可以发布
- 任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
- 在团队里工作，修改一些东西的时候必须很谨慎。你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。
14、 提早集成，频繁集成
- 绝不要做大爆炸式的集成。
- 提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
- 如果你集成得不够频繁（比如一周一次，甚至更糟），也许就会发现整天在解决代码集成带来的问题，而不是在专心写代码。如果你集成的问题很大，那一定是做得不够频繁。
15、 提早实现自动化部署
- 一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
- 部署一个紧急修复的bug 应该很简单，特别是在生产服务器的环境中。你知道这会发生，而且你不想在压力之下，在凌晨三点半，你还在手工部署系统。
16、 使用演示获得频繁反馈
- 维护一份项目术语表。在项目的开发过程中，从术语表中为程序结构——类、方法、模型、变量等选择合适的名字，并且要检查和确保这些定义一直符合用户的期望。
- 清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
17、 使用短迭代，增量发布
- 增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1 ～ 4 周左右迭代周期。
18、 固定的价格就意味着背叛承诺
- 软件项目天生就是变化无常的，不可重复。如果要提前给出一个固定的价格，就几乎肯定不能遵守开发上的承诺。
- 基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
五、敏捷反馈
19、 守护天使
- 一些开发者会对单元测试有意见：毕竟，有“测试”这个词在里面，毫无疑问这应该是其他人的工作。从现在开始，忘掉“测试”这个词。就把它看作是一个极好的、编写能产生反馈的代码的技术。
- 使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何代码设计和代码修改。
- 人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。
20、 先用它再实现它
- 设计的一个重点是：确定什么是成功地实现特定功能的最低成本。程序员很容易走向另一个极端——一些不必要的过于复杂的事情——测试优先会帮助我们，防止我们走偏。
- 先用它再实现它。将TDD 作为设计工具，他会为你带来更简单更有实效的设计。
21、 不同环境，就有不同问题
- 不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
22、 自动验收测试
- 为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
23、 度量真实的进度
- 我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
- 在你最后真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。在为下一个任务估计工作量时，可以根据这次经验调整评估。
24、 倾听用户的声音
- 不管它是否是产品的bug ，还是文档的 bug ，或者是对用户社区理解的 bug ，它都是团队的问题，而不是用户的问题。
- 每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。
六、敏捷编码
25、 代码要清晰地表达意图
- 开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过代码编写的次数，所以在编写的时候值得花点功夫让它读起来更简单。
- 要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明。
26、 用代码沟通
- 用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能代替优秀的代码。
27、 动态评估取舍
- 动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
- 如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）。
- 过早的优化是万恶之源。
28、 增量式编程
- 在很短的编辑、构建、测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
- 要像重构你的代码那样，重构你的测试，而且要经常重构测试。
29、 保持简单
- 开发可以工作的、最简单的解决方案。除非有不可辨驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
- 要将目标牢记在心：简单、可读性高的代码。强行让代码变得优雅与过早优化类似，统一会产生恶劣的影响。
30、 编写内聚的代码
- 让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不用创建无所不包的大杂烩类。
31、 告知，不要询问
- 面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。
- 作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是你的。
- 告知，不要询问。不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
32、 根据契约进行替换
- 通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
七、敏捷调试
33、 记录问题解决日志
- 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
- 如果通过搜索Web ，发现没人曾经遇到同样的问题，那也许是搜索的方法有问题。
34、 警告就是错误
- 将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
35、 对问题各个击破
- 很多应用的代码在编写时没有注意到隔离问题这一点，使得分离变得特别困难。此时，最好花一些时间把关注的代码提取出来，而且创建一个可让其工作的测试环境。
- 对问题各个击破。在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。
36、 报告所有的异常
- 处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。
37、 提供有用的错误信息
- 展示有用的错误信息。提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
八、敏捷协作
38、 定期安排会面时间
- 使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。
- 要保证会议议题不发散，每个人都应该只回答下述三个问题：
- 昨天有什么收获？
- 今天计划要做哪些工作？
- 面临着哪些障碍？
- 虽然大多数团队需要每天都碰头，但对于小型团队来说，这样做可能有点过头了。不妨两天举行一次，或者一周两次，这对小团队来说足够了。
39、 架构师必须写代码
- 设计会随着时间而演进，如果忽略了应用的现状（它的具体实现），要想设计一个新的功能，或者完成某个功能的提升，是不可能的。
- 优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。
- 不要运行任何人单独进行设计，特别是你自己。
40、 实行代码集体所有制
- 在团队中实行任务轮换制，让每个成员都可以接触到不同部分的代码，可以提升团队整体的知识和专业技能。
41、 成为指导者
- 成为指导者。分享自己的知识很有趣——付出的同时便有收货。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
- 如果一直在就同一个主题向不同的人反复阐述，不妨记录笔记，此后就此主题写一篇文章，甚至是一本书。
42、 允许大家自己想办法
- 给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。每个人都能从中学到不少东西。
43、 准备好后再共享代码
- 准备好后再共享代码。绝不要提交尚未完成的代码。故意签入编译未通过或是没有经过单元测试的代码，对项目来说，应被视为玩忽职守的犯罪行为。
44、 做代码复查
- 复查所有的代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成功。要让不同的开发人员在每个任务完成后复查代码。
- 同样的功能，不同开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码变得更好，否则不要随意批评别人的代码。
- 如果不及时跟进讨论中给出的建议，代码复查是没有实际价值的。可以安排跟进会议，或者使用代码标记系统，来标识需要完成的工作，跟踪已经处理完的部分。
45、 及时通报进展与问题
- 及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。
九、尾声：走向敏捷
Bug Fix
c85e 
程序员