代码质量之可维护性

2014-11-24 02:01:17 · 作者: · 浏览: 0

我的心态变化

c = a

a = b

b = c

后来我我从师兄那学到了下面这段代码,觉得写的比我之前的更漂亮:

a = a + b

b = a - b

a = a - b

最后参加工作了,看到很多别人的代码,最后又觉得最漂亮的代码是这样的:

c = a

a = b

b = c

请问大家,为什么我的心态有这样的变化?

软件开发的现实

  • 一个软件生命周期中,80%的时间和精力花费在维护阶段。
  • 几乎没有任何一个软件,在其整个生命周期中,均有最初的开发人员维护。
  • 几乎没有任何一个软件,在其整个生命周期中,它的文档与代码是保持同步的。
场景再现

有两种人,第一种人维护的是自己的代码,但是,随着时间的流逝,以前的关于系统的理解和记忆已经逐渐消失了,每次修改bug或增加新功能时,要通过看文档、看代码来回忆当时开发系统的场景。第二种人,代码不是自己写的,需要阅读相关文档和代码,为了弄明白某一处代码的意图,需要了解整个模块的逻辑流程,还要看相关需求和设计文档,但是很遗憾,这些文档都和实际代码不同步。

影响可维护性的因素

1.是否是同一个开发人员

2.人的质量如何,技术功底,对业务领域的熟悉程度

落地措施

1.提高自身的质量,技术功底(面向对象、重构),熟悉业务,多与同事face to face交流

其实,维护软件最头痛的是,随着时间的流逝,以前的关于系统的理解和记忆已经逐渐消失了。每次修改bug或增加新功能,要通过看文档,看代码来回忆当时开发系统时的场景。

软件质量特性中最重要的我认为是可维护性,而可维护性的前提是可理解性。

我们要理解谁?

2.理解文档,信息只有被用心组织才能有更好的可理解性。

3.理解代码,好的代码会自解释,会说话,坏的代码面目狰狞,五官发育不全,代码的可理解性是靠开发人员来控制的,是造一个天使还是一个怪物,全看我们的态度是怎么样的。

可理解性强的代码不是一门技术,而是一门艺术。