来源: 捷道  发布时间: 2011-09-10 22:49  阅读: 1939 次  推荐: 0                  原文链接                  [收藏]  

  我始终认为,代码应作为架构的一部分,不如此,不足以表达代码质量的重要性。我知道,这与传统学院派 对架构的定义是相悖的。一般认为,架构是描述设计蓝图的宏观过程,然而,敏捷方法的逐步普遍,却慢慢开始颠覆这种事前设计的论调,代码不仅要体现架构的原 则与思想,还要通过代码对架构施加影响,甚至利用代码来补充与完善架构。

  Yourdon与Constantine认为软件系统的整体成本等于开发成本加维护成本,而后者成本远远大于开发成本。维护成本包括理解、变 更、测试与部署的成本。其中,所谓“理解”主要还在于维护人员如何理解代码,尤其是当变更发生时。只有清晰的代码结构,才有助于我们理解系统;也只有清晰 的代码结构,才能提高代码质量。所以,我认为代码是纳米架构(Nano Architecture)的一部分。

  在将代码提升到一定高度之后,再让我们来看看如何改善代码质量。除了需保持代码的清晰与可读性之外,代码的数量也开始获得了人们的关注。InfoQ最近发表了新闻《代码是债务,越少越好》, 根据精益方法中的库存得到减少代码数量的结论。《修改代码的艺术》(英文书名Working Effectively with Legacy Code)的作者Michael Feathers最善于处理遗留代码,他认为“代码也是我们持有的库存,并且需要最小化。”这篇新闻中摘录的观点都是警示之语,唤起了我们对代码数量的关 注。

  就本人而言,我认为减少代码量的最佳做法莫过于提高代码的重用性。《程序员修炼之道》中认为,重复的类型包括:  
  1、强加的重复    
  2、无意的重复    
  3、无耐性的重复    
  4、开发者之间的重复

  综合而论,我认为导致代码重复的原因有三个:  
  1、懒惰,所以能够容忍不好的代码;    
  2、技能不足,常常会出现不必要的重复代码;    
  3、缺乏沟通,团队之间协作不够,因而重复制造轮子。

  重用的关键是保持合适的粒度,以及对关系的解耦。粒度表现在方法级,就是需要编写许多小的方法,找到类中可以重复调用的职责,抽取为单独的方 法。类级的粒度可以采用辅助类,也可以通过寻找共性,以泛化的方式提取共性特征。对于模块级,则主要需考虑模块的复用原则,合理解除模块之间的依赖关系。

  之所以出现很多糟糕混乱的遗留代码,主要原因还是在于职责的分配与分离做得不够好。职责的分配不准确,就可能导致代码结构不清晰,而职责的分离 做得不好,就可能导致代码的重复。在经历了太多维护遗留代码的工作后,我往往发现这些遗留代码都没有做好模块的划分,而是率意为之,有时候甚至会出现一个 庞大的项目,包含了数据访问、业务逻辑与界面表现等所有对象,这意味着它没有合理的分层架构。我现在在设计和开发时,非常注意对模块的划分,尽量避免模块 之间的双向依赖与循环依赖。同时,还要站着发布的角度来思考模块的划分与定义。在编码时,我会思考类的归属,要让其放到合适的位置,既表达出它的职责,又 不会产生纠缠不清的依赖。

  我们还可以通过用例识别重用。在用例图中,存在包含、扩展与泛化关系的用例,都可能是潜在的重用点。