主页 > 知识库 > 网络编程 > PHP >

PHP

程序员编程十条戒律(2)

来源:互联网 作者:PHPer 发表于:2009-09-29 10:48  点击:
物理层组织:无论你使用什么样的目录,包(package)或名字空间(namespace)等的结构,你需要把你的类用一种标准的方法组织起来,这样可以方便查找。这是一种物理性质的代码组织。 逻辑层组织: 所谓逻辑层,主要是说

 

物理层组织:无论你使用什么样的目录,包(package)或名字空间(namespace)等的结构,你需要把你的类用一种标准的方法组织起来,这样可以方便查找。这是一种物理性质的代码组织。
逻辑层组织: 所谓逻辑层,主要是说,我们如果把两个不同功能的类或方法通过某种规范联系和组织起来。这里主要关注的是程序模块间的接口。这就是我们经常见到的程序模块的架构。
6.- 创建大量的单元测试
单元测试是最接近BUG的地方,也是修改BUG成本最低的地方,同样也是决定整个软件质量好坏的成败的地方。所以,只要有可能,你就应该写更多的,更好的单元测试案例,这样当你未来有相应代码改变的时候,你可以很简单知道你代码的改变是否影响了其它单元。

7.- 经常重构你的代码
软件开发是一种持续的发现的过程,从而让你的代码可以跟上最新的实际需求的变化。所以,我们要经常重构自己的代码来跟上这样的变化。当然,重构是有风险的,并不是所有的重构都是成功的,也不是我们随时都可以重构代码。下面是两个重构代码的先要条件,以避免让你引入更多的BUG,或是把本来就烂的代码变得更烂。

有大量的单元测试来测试。正如前面所说,重构需要用大量的单元测试来做保障和测试。
每次重构都不要大,用点点滴滴的小的重构来代替那种大型的重构。有太多的时候,当我们一开始计划重构2000行代码,而在3个小时后,我们就放弃这个计划并把代码恢复到原始的版本。所以,我们推荐的是,重构最好是从点点滴滴积累起来的。
8.- 程序注释是邪恶的
这一条一定是充满争议的,大多数程序员都认为程序注释是非常好的,是的,没错,程序注释在理论上是非常不错的。但是,在实际过程序当中,程序员们写出来的注释却是很糟糕的(程序员的表达能力很有问题),从而导致了程序注释成为了一切邪恶的化身,也导致了我们在阅读程序的时,大多数时候,我们都不读注释而直接读代码。所以,在这里,我们并不是鼓励不写注释,而是——如果你的注释写得不够好的话,那么,你还不如把更重要的时间花在重构一下你的代码,让你的代码更加易读,更加清楚,这比会比注释更好。

9.- 注重接口,而不是实现
这是一个最经典的规则了。接口注重的是——“What”是抽象,实现注重的是——“How”是细节。接口相当于一种合同契约,而实际的细节相当于对这种合同契约的一种运作和实现。运作是可以很灵活的,而合同契约则需要是相对需要稳定和不变的。如果,一个接口没有设计好而需要经常性的变化的话,那我们可以试想一下,这代来的后果,这绝对会是一件成本很大的事情。所以,在软件开发和调设中,接口是重中之重,而不是实现。然而我们的程序员总是注重于实现细节,所以他们局部的代码写的非常不错,但软件整体却设计得相对较差。这点需要我们多多注意。

10.- 代码审查机制
所有人都会出错,一个人出错的概率是很大的,两个人出错的概率就会小一些,人多一些,出错的概率就会越来越小。因为,人多了,就能够从不同的角度看待一个事情,虽然这样可能导致无效率的争论,但比起软件产品release后出现问题的维护成本,这点成本算是相当值得的。所以,这就是我们需要让不同的人来 reivew代码,代码审查机制不但是一种发现问题的最有效的机制,同时也是一种可以知识共享的机制。当然,对于Code Review来说,下面有几个基本原则:

审查者的能力一定要大于或等于代码作者的能力,不然,代码审查就成了一种对新手的training。
而且,为了让审查者真正负责起来,而不是在敷衍审查工作,我们需要让审查者对审查过的代码负主要责任,而不是代码的作者。
另外,好的代码审查应该不是当代码完成的时候,而是在代码编写的过程中,不断地迭代代码审查。好的实践的,无论代码是否完成,代码审核需要几天一次地不断地进行。

有帮助
(42)
82.4%
没帮助
(9)
17.6%
  • 上一篇:没有了
  • 下一篇:PHP :time(),date(),mktime()区别