2.6.4　度量可维护性

评估可维护性至少需要检查下列软件工程实践和技术属性。

●应用程序架构实践

　■多层设计一致性

　■耦合度

　■组件或模式重用度

●编程实践（代码级）

　■与面向对象和结构化最佳编程实践的一致性（适用时）

●复杂度

　■事务复杂度

　■算法复杂度

　■编程实践复杂度

●不当编程

●文档

　■代码可读性

　■嵌入在源代码中的架构、程序和代码文档

　■源代码文件的组织和清洁度

●可移植性

　■硬件、操作系统、中间件、软件组件和数据库依赖

●技术和功能量

　■每种技术的LOC数、制品数、文件数和功能点数

无论何时，如果多层应用程序中的架构实践没能实施，那开发人员要实现一个改动就得耗费过多的时间找出要修改的点，还得跟踪其潜伏在不同层间的副作用。忽视架构准则和面向对象设计原则（如继承的误用）会让应用程序特性极其难于识别和跟踪。组件间的高耦合也会导致更多的时间耗在给定的维护工作上，因为开发人员和测试人员必须保证，对组件的改动不会给使用了该组件的所有其他组件带来不良影响。研究表明，维护工程师大约50%的时间用于在修改前去理解代码的作用，这一点毫不奇怪。当一个过于复杂的应用程序转交给一个新团队时，他们会努力理解其组织结构，而真正有产出可能需要一年甚至更长的时间。软件质量的这些长期违例和恶化经常被称为设计腐蚀（参见"Design Erosion in Evolving Software Products"一文：http://soft.vub.ac.be/FFSE/Workshops/ELISA-submissions/06-VanGurpEtAl-position.pdf）。

一般来说，特定的编程技术（如动态实例化或动态编程）都需要高水平的专门技能、非常慎重的编码和更多的时间来找出在哪里以及如何作出改动（参见"Use of Inheritance and Polymorphism in a Reliable Software System"一文：http://www.aicas.com/papers/DA_Scharnberg.pdf）。应用程序的可维护性很大程度上也取决于复杂度。编码、算法和控制流复杂度，以及特定的编程技术（如动态编码）虽然优雅，但会增加维护时间和成本。

命名和编码习惯的一致性能让源代码准确、可读性强且明确，这样能加快理解代码的速度并让代码发现更直观。最后，软件的大小也会影响其可维护性。软件规模的增长意味着其复杂度的增加（更多的制品，制品间更多的依赖，从而一旦改动后会有更多的影响）。