《高效程序员的45个习惯》读后感

感受

• 敏捷开发人员必读。
• 关于书名。从内容看来，原书名《Practices of an Agile Developer》比中文书名更加贴切。
  
• 关于文字和排版。作者的表达很不错，章节编排和内容排版也很好。
  
• 关于翻译。虽然偶尔会觉得有些句子过于冗长，但总体感觉还不错。
  
• 很幸运的，我也读了本书作者 Andy Hunt 的另一本书《程序员的思维修炼》，书中在讲德雷福斯模型时说到，“他们（精通者）具有经验和判断力，能够理解这句格言在情境中意味着什么。事实证明，理解情境是成为专家的关键。”这两句话对我读『高效程序员的45个习惯』有很大的帮助。这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

1、94页第3段第1行，“代办事项”应为“待办事项”。