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

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

不觉间，走入编程的世界已经2年了，没有做出什么值得说道的成绩，也没有什么伟大的事迹。两年，是个说长不长，说短不短的时间，在这个时间内，也许自己已经发生了改变，却没有达到质变的程度吧。但是两年也可以理清一些事情，决定一个方向。两年的编程确定的事情：

1）程序员是可以不分性别的，需要的只是努力和付出。只要认真了，无论有无基础，总是可以适应的。

2）程序员不是高薪的工作，指望初出茅庐就可以赚大钱的希望，彻底破灭了。但是编程节也是有神人的存在，高收入自然是不必说的，这也给在温饱线挣扎的程序员一个念想。

3）程序员需要高度的学习热情。在技术日新月异的时代，要时刻提升丰富自己所学，才能不被淘汰。

4）程序员需要一个擅长的领域，要在某一个顶点傲视群雄。这点也是程序员的自尊和自信所在吧。

总是戏说自己是在编程界混日子的，没有发现自己喜欢做的事情。偶尔甚至安慰自己说，如果确定了自己喜欢的事情，一定可以做得非常优秀的。这时才发现，欺骗自己久了，都不知道那是谎言了。偶尔想想，人生总要做成一件令自己满意的事情，才对得起自己吧。决定在编程界走下去了，就要喜欢他、享受他、可以站在顶点。决定了以后，才发现自己还有很长的路要走。“路漫漫其修远兮，吾将上下而求索”，真是“学而时习之，温故而知新”。

牢骚发完了，进入正题吧。高效程序员的45个习惯，是介绍敏捷开发的。当然，在目前速食似乎已经成了任何行业的一种流行素。个人认为即使项目不是敏捷开发模式，该书介绍的45个习惯也能提高程序员本身的技能的。

本书的翻译者之一安川，大概是骨灰级的武侠迷吧，本人也很喜欢他为敏捷所写的歌诀，在此就搬过来吧。

迭代开发，价值优先

分解任务，真实进度

 

站立会议，交流畅通

用户参与，调整方向

 

结对编程，代码质量

测试驱动，安全可靠

 

持续集成，尽早反馈

自动部署，一键安装

 

定期回顾，持续改进

不断学习，提高能力

 

此歌诀，也许道尽了真理吧，才疏学浅，还不能尽数理解。

敏捷综述：敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。

 

第二章 态度决定一切：

 

习惯1：做事。指责不会修复bug。把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。

习惯2：欲速则不达。不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。

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

习惯4：排除万难，奋勇前进。做正确的事。要诚实，有勇气去说出实情。有时，这样做很困难，所有我们要有足够的勇气。

 

第三章 学无止境：

 

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

习惯6：对团队投资。提供你和团队学习的更好平台。通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集在一起进行沟通交流。唤起人们对技术和技巧的激情，将会对项目大有裨益。

习惯7：懂得丢弃。学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强很多。

习惯8：打破沙锅问到底：不停地问为什么。不能只满足于别人告诉你的表面现象。要不停的提问知道你明白问题的根源。

习惯9：把握开发节奏。解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。

 

第四章 交付用户想要的软件：

 

习惯10：让客户做决定。让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题并让他们做决定。

习惯11：让设计指导而不是操纵开发。好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计（或者设计师）操纵。

习惯12：合理地使用技术。根据需要选择技术。首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对任何要使用的技术，多问一些挑剔的问题，并真实地做出回答。

习惯13：保持可以发布。保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。

习惯14：提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。

习惯15：提早实现自动化部署。一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要想测试应用一样测试部署。

习惯16：使用演示获得频繁反馈。清晰可见的开发。在开发的时候，要保持应用可见（而且客户中心也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。

习惯17：使用短迭代，增量发布。发布带有最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。

习惯18：固定的价格就意味着背叛承诺。基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。

 

第五章 敏捷反馈：

 

习惯19：守护天使。使用自动化的单元测试。好的单元测试能够为不的到哪问题提供及时的警报。如果没有到位的单元测试，不要进行任何测试和代码修改。

习惯20：先用它在实现它。先用它在实现它。将TDD（Test DrivenDevelopment，测试驱动开发）作为设计工具，它会为你带来更简单更有实效的设计。（PS：测试驱动开发，你总是在有一个失败的单元测试才开始编码。测试总是先编写。通常，测试失败要么是因为测试的方法不存在，要么是因为方法的逻辑还不足以让测试通过。）

习惯21：不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等待问题来找你。

习惯22：自动验收测试。为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动的运行。（PS：FIT，继承测试框架，可以很容易地使用HTML定义测试用例，并比较测试结果数据。）

习惯23：度量真实的进度。度量剩余的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。

习惯24：倾听用户的声音。每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。

 

第六章 敏捷编码

 

习惯25：代码要清晰地表达意图。要编写清晰地而不是讨巧的代码。向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明。

习惯26：用代码沟通。用代码沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。

习惯27：动态评估取舍。动态评估取舍。考虑性能、便利性、生产力、成本和上市的时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。

习惯28：增量式编程。在很短的编辑/构建/测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作要好的多。可以创建更加清晰、简单、易于维护的代码。

习惯29：保持简单。开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，都则不要使用模式、原则和高端度的技术之类的东西。

习惯30：编写内聚的代码。让类的功能尽可能集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。

习惯31：告知，不要询问。不要抢别人的对象或者是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。

习惯32：根据契约进行替换。通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性，要多使用委托而不是继承。

 

第七章 敏捷调试

习惯33：记录问题解决日志。维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。

习惯34：警告就是错误。将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应爱产生任何警告信息。

习惯35：对问题各个击破。对问题各个击破。在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。

习惯36：报告所有的异常。处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行，在写代码时，要估计到会发生的问题。

习惯37：提供有用的错误信息。展示有用的错误信息。提供更易于查找错误细节的方式，发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。（区分错误类型：程序缺陷，环境问题，用户错误）。

 

第八章 敏捷写作

习惯38： 定期安排会面时间。使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。10-15分钟比较好。

习惯39：架构师必须写代码。优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。

习惯40：实行代码集体所有制。要强调代码的集体所有制。让开发人员轮换完成系统不同模块的不同任务。

习惯41：成为指导者。成为指导者。分享自己的知识很有趣——付出的同时便有收获。还可以激励比二年获得更好的成果，而且提升了整个团队的实力。

习惯42：允许大家自己想办法。给别人解决问题的机会。指给他们正确的方法，而不是直接提供解决方案，每个人都能从中学到不少东西。

习惯43：准备好后在共享代码。绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对项目来说，应该视作玩忽职守的犯罪行为。

习惯44：做代码复查。复查所有的代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而且高效的成果。要让不同的开发人员在每个任务完成后复查代码。

习惯45：及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目的状态如何。

（完）