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

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

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

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

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

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

 

用代码沟通

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

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

 

动态评估取舍

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

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

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

 

增量式编程与测试(指编程的时候)

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

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

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

 

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

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

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

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

 

告知,不要询问

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

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

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

 

根据契约进行替换

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

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

 

posted @ 2016-08-17 11:10  郁闷紫番薯  阅读(95)  评论(0编辑  收藏