性能误区- -| 回首页 | 2005年索引 | - -内存管理

可维护性——你重视起来了吗?- -

                                      

伟人小平同志曾经说过,当今世界的两大主题是:和平与发展。

但,和平从来也没有真正到来过,发展却也从来没有停止过。

谈到发展,首先要能生存下来。如果生存问题都解决不好,谈发展纯粹是扯淡。

对于一个软件产品来讲,如果功能与性能无法满足用户的需要,这个产品对用户来讲就是一个废物,其结局注定是——死亡。所以,我们在开发一个产品之前,一定要搞清楚用户对于功能和性能的需求,随后再进行设计和开发。

但,一般来讲,生存问题总是相对容易解决的,注意,我说的是相对容易,因为在某些时候,想生存下来也是那么艰难。可是,相对于过上体面富足的生活而言,生存下来毕竟要容易的多。

在一个产品的功能和性能能够满足用户的基本需要之后,我们肯定想要的是让这个产品能够很好的发展下去。而不是像一次性尿布,用完就丢。

但如何让产品能够发展下去,却是一个相当有挑战性的问题。有太多的产品从第一个版本发布之后,由于后续的需求变更,设计变更,错误排除等等原因,逐渐变质,走向腐烂,走向灭亡。就像历史上的一个个王朝,刚刚建国的时候,一派新气象,一度还走向鼎盛时期,但最终都逃脱不了变质,衰落,灭亡的命运。

并非这些王朝的领导者们不想让社会发展,而是从最初就没有建立一套纠错能力非常好的机制。为什么美国能够在建国之后,能够持续不断的得到发展,不是天佑美国,而是它的开国者和后来者们逐步建立了一套非常良好的便于随时修正错误的机制。在软件领域,这种机制叫做可维护性。

我们当前政府的很多领导者,由于对于可维护性认识不足,很多房屋,马路刚建了没几年,就由于其不符合当前的规划被拆了重建,所以我们的城市经常能够看到拆拆建建的场面,浪费了无数纳税人的血汗。

我们不是政府的决策者,但我们可以对自己正在做的事情作出决策。在我们大骂这些官僚无能时,作为程序员,我们是否也应该审视一下自己,我们对自己软件的可维护性是否有了足够的重视?

如果一个系统的可维护性从最初没有得到很好的重视,当系统面临重大的设计改动时,会发现几乎无法入手,最简单的方法是彻底推翻重写,于是造成大量的资源浪费。这种例子屡见不鲜,任何一个有点经验的程序员都能够信手举出几个例子。

在软件领域,存在很多很多方法,可以有利于增强系统的可维护性,我并不打算也不可能将其一一列举。仅仅列出几个常见的以说明问题:

1)灵活的架构

架构设计是一个系统非常重要的因素。一个架构的良好与否,重要的指标之一,就是其是否具备良好的可维护性。如何进行架构设计,是一个很大的话题,请参考相关著作。

2)编码规范

所有的命名方式,缩进风格,调用方法,都应该有统一的规范。这样,无论对于编码者,还是维护者,都更有利于代码的阅读和理解。

3)清晰,完整,准确的命名

不要忽略名字的重要性。当前的语言和编译器都会允许很长的标识符,所以不要怕使用很长的名字。如果名字自身就能说明完整清晰的语义,你就无需再写相关注释。必须明确一点,注释也是要维护的,维护注释是更容易被忽略的事情,从而给整个系统的维护带来麻烦。

4)不要写很长的函数

过长的函数导致阅读起来非常困难。另外,一般来说,过长函数中肯定会有很相似的代码,对这些相似代码的维护需要付出更多的effort,而把它们分离到新函数中,能够减少代码数量,让代码更加容易理解,更容易修改。我见过一个初级程序员写了一个上千行的函数,经过拆分后,只有三百多行代码,看起来可读性更强,也更容易修改了。

......

即使仅仅从美学的角度来看,可维护性也是非常重要的。因为一个可维护性很强的系统充满着和谐的美感。而一个出色的程序员首先应该是一个艺术家。如果你正在开发或维护者一段可维护性很差的程序,你的心情一定很烦躁。我自己就有过深刻体会。当时,由于时间很紧,我甚至无法在规定的时间内完成功能需求,根本不可能有时间去考虑其他因素。结果是,最终代码完成之后,确实能够正常工作,但我在维护的时候,我一看到我的代码就想吐,那段时间是我脾气最坏的时候,一点小事情就会让我大发雷霆。

最后,按照惯例,需要总结一下:如果你具有长远的眼光,如果你想让自己开发的系统能够得到发扬光大,那么请把可维护性放到更加重要的位置上来,最终你会发现,你得到的要比你付出的多得多。

- 作者: 上帝没发笑 2005年01月31日, 星期一 04:22 加入博采

Trackback

你可以使用这个链接引用该篇文章 http://publishblog.blogchina.com/blog/tb.b?diaryID=650123

回复

评论内容: