高效程序员的45个习惯 敏捷开发修炼之道 读书笔记 第六章 敏捷编码

代码要清晰地表达意图（PIE原则 program intently and expressively）

这个问题强调过不少遍的。

命名问题参见：代码整洁之道,对命名问题讲得很好。

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

如今对弈显而易见的事情，对别人可能并不是如此，对于一年之后的你来讲，也不必定显而易见。

 

用代码沟通

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

注释就像是是能够帮助你的好朋友，能够先阅读注释，而后快速浏览代码，从而彻底理解它作了什么，以及为何这样作。

 

动态评估取舍

动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。若是性能表现足够了，就将注意力放在其余因素上。

不要为了感受上的性能提高或者设计的优雅，而将设计复杂化。

不要过分设计，最重要是适合，即便不能面面俱到，你也应该以为已经获得了最重要的东西--客户认为有价值的特性。

 

增量式编程与测试（指编程的时候）

在很短的编程/构建/测试循环中编写代码。这要比花费长时间仅仅作编写代码的工做好得多。能够建立更加清晰、简单、易于维护的代码。

长时间编码后再想测试，出的问题每每容易摸不着头脑，不利于在代码中发现问题。

页面测试、控件测试、页面功能实现后测试我通常分为。

 

保持简单、编写内聚的代码

开发能够工做的、最简单的解决方案。除非有不可辩驳的缘由，不然不要使用模式、原则和高难度技术之类的东西。

让类的功能尽可能集中。让主键尽可能小。要避免建立很大的类或组件，也不要建立无所不包的大杂烩类。

体会项目分类准确，图片、IO、控件等等相应的工具类要分好地方，在项目中不要出现类似名字的类也不要出现常常性复制代码，以前在公司的项目就存在不少代码重复的地方，一控件作的不够可扩展，二是一些工具类没有设计相应的存放的地方，致使这些类在其余包不可见，只能复制过去。

 

告知，不要询问

 命令与查询相分离模式（command-query separation），将功能和方法分为这两类并在源码中记录下来。

不要抢别的对象或是组件的工做。告诉它作什么，而后盯着本身的职责就行了。

不能容许一个看起来无辜的查询去修改对象的状态

 

根据契约进行替换

当使用继承时要想一想派生类是否能够替换基类，若是答案是不能，而是但愿在编写新类的时候重用基类中的代码，也须要考虑转而使用聚合。

经过替换代码来扩展系统。经过替换循环接口契约的类，来添加并改进功能特性。