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

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

这个问题强调过很多遍的。

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

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

现在对弈显而易见的事情，对别人可能并非如此，对于一年以后的你来说，也不一定显而易见。

 

用代码沟通

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

注释就像是是可以帮助你的好朋友，可以先阅读注释，然后快速浏览代码，从而完全理解它做了什么，以及为什么这样做。

 

动态评估取舍

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

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

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

 

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

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

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

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

 

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

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

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

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

 

告知，不要询问

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

不要抢别的对象或是组件的工作。告诉它做什么，然后盯着自己的职责就好了。

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

 

根据契约进行替换

当使用继承时要想想派生类是否可以替换基类，如果答案是不能，而是希望在编写新类的时候重用基类中的代码，也需要考虑转而使用聚合。

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