《高效程序员的45个习惯》总结
一、敏捷——高效软件开发之道
敏捷的精神：它要求团队中的每一个人（包括与团队合作的人）都具备职业精神，并积极地期望项目能够获得成功。它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。 二、态度决定一切
1、 做事
符合标准不是结果。敏捷团队重结果胜于重过程。
胎盘屏障
指责不能修复bug 。把矛头对准问题的解决办法，而不是人。 2、 欲速则不达
不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。 不要急于修复一段没能真正理解的代码。这种 +1/-1 的病症始于无形，但是很快会让代码一团糟。要解决真正的问题，不要治标不治本。
所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
3、 对事不对人
唯美主义运动我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。
脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太容易发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗？是否经常
发生？
4、 排除万难，奋勇前进
做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
三、学无止境
5、 跟踪变化
跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
许多新想法从未变得羽翼丰满，成为有用的技术。即使是大型、热门和资金充裕的项目也会有同样的下场。你要正确把握自己投入的精力。
6、 对团队投资
你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。
坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。
7、 懂得丢弃
打破旧习惯很难，更难的是自己还没有意识到这个问题。丢弃的第一步，就是要意识到你还在使用过时的方法，这也是最难的部份。
8、 打破沙锅问到底
不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
你可能会跑题，问了一些与主题无关的问题，这样的问题是没有任何帮助的。要问到点子上。
9、 把握开发节奏
解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
在每天结束的时候，测试代码，提交代码，没有残留的代码。 四、交付用户想要的软件
寻乌调查
10、 让客户做决定
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
即使初始的设计到后面不再管用，你仍需设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程必不可少。”在设计过程中学习是有价值的，但设计本身也许没有太大的用处。
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、 对问题各个击破
很多应用的代码在编写时没有注意到隔离问题这一点，使得分离变得特别困难。此时，最好花一些时间把关注的代码提取出来，而且创建一个可让其工作的测试环境。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议