程序代码可控性研究

邵改革

摘要摘要：程序代码编写不规范、缺乏可扩展性和可维护性，将导致代码可控性较差，严重影响软件产品的持久更新升级。从代码质量控制角度出发，通过对程序代码的可控性进行研究，提出代码可控性评价标准，并给出改进措施。代码的可控性有助于缓解程序扩展和修改压力，形成代码更新迭代的良性循环。

关键词关键词：程序可控性；代码可量测；代码质量评价

DOIDOI：10.11907/rjdk.162173

中图分类号：TP319文献标识码：A文章编号文章编号：16727800（2017）001012402

引言

随着用户需求的不断变化，软件结构日益复杂，开发周期越来越短，如何按时交付高质量的产品成为软件开发工作的一个难点。提高软件质量和开发效率关乎软件企业竞争力，也是每个信息化企业不懈追求的目标。软件研发是一项系统性工程，包括需求分析、系统设计、系统实现、测试等环节[1]。针对研发过程，国内外专家学者结合具体实践，从不同角度提出了提高软件质量的方法和模型。虽然软件开发具有诸多过程管理方法和经验，如CMM（Capability Maturity Model for Software）、PMBOK（项目管理知识体系）、敏捷开发等，但目前软件质量依然不容乐观。软件质量水平不高是由很多方面因素所致，其中最主要的原因之一在于程序代码缺乏可控性。

以笔者所在单位的部分产品代码为例，整个产品线包括较为完善的单元测试、集成测试、系统测试和性能测试，但对程序代码层面的问题关注较少，没有形成一套完整的代码质量评价体系。代码中仍然存在命名规范差、重复代码、长方法、大类、长参数列表、滥用设计模式等问题，初期表现为程序代码可读性差。随着软件产品根据用户需求不断修改升级和不同版本累积，程序的可控性逐渐变差，代码变得难以理解和修改，软件产品版本维护越来越困难。

1代码质量控制

软件质量是指软件产品满足预定需求的程度。Boehm等[2]提出了软件质量评价的概念，并使用定量公式用于评价软件质量。McCall和Waters[3]提出了从软件质量要素、准则到度量的三层次质量度量模型。ISO提出的质量度量模型由高层软件质量需求评价准则、中层软件质量评价设计准则和底层软件质量度量评价准则3个层次组成。代码质量评价指标一般包括正确性、规范性、可读性、有效性、可扩展性、可重用性、可维护性、安全性等[4]。上述评价指标从不同层面对代码进行了评估，但缺乏具体的评价标准和方法，代码评价指标在实际操作中难以适用。比如可读性指标，代码“可读性”与“不可读性”的界限比较模糊，但具有良好可读性的代码一定具有注释、规范的命名和适当的结构等特征[5]。命名规范有很多种，但良好的规范性代码往往遵循统一的命名方法。

提高代码质量是软件企业增强竞争力的重要策略之一，更是以软件产品为主导型信息企业长久发展的基石。但由于种种原因，程序代码质量并未达到理想的目标，代码质量不高的原因主要有：

（1）缺乏顶层设计理念。任何一种设计或架构方案，都需要一个良好的控制机制来实现，不能将设计与实现脱节。系统总体设计不仅仅是一个图形或文档，需要融入到程序结构和具体的代码实现过程之中。

（2）缺乏中间代码结构的设计过程。顶层设计需要中间代码结构设计才能过渡到具体的代码实现，该过程由设计方案变成软件架构，是软件开发比较重要的一次模式转换。缺少此过程，将会导致顶层设计和实现代码之间的割裂。

（3）开发人员水平参差不齐和代码版本差异大。开发人员基础较差、缺乏经验加上对设计方案的理解程度不同，在对程序代码的维护中往往加入“坏味”代码较多。并且一个产品线有时需要维护不同的代码版本，而不同版本在演化过程中相差会越来越大，代码中存在大量的交叉和重复。

（4）代码质量检查环节薄弱。产品测试只注重单元测试、集成测试、系统测试和性能测试，忽略了代码质量检查。这些测试只保证了代码的外在表现，未能体现代码的内在质量。“坏味”代码一旦进入版本库，会产生一系列程序问题，增加软件维护工作量。

上述问题的存在导致代码的可控性越来越低，后期更新维护成本越来越高。程序代码的可控性主要是指对于代码需要修改和扩展的可量测性大小，它是代码质量评价的主要指标之一，在以产品为主导的开发中格外重要。具有良好可控性代码的程序可以有效应对变化，各环节之间的影响程度是可以界定的。它有助于合理调配资源，优化开发工作流程，减轻维护人员工作量，利于产品代码的重构和版本演化。

2代码可控性评价

（1）需求改变导致的代码修改具有明确的范围。用户需求日益个性化、精细化，软件领域用户需求变化成为了一种客观规律。一旦用户需求发生变更，程序代码就要作出相应调整。在这种变化常态下，如何减少需求改变带来的代码修改是程序面临的难题。具有良好可控性的程序代码，如遇需求更改，可快速定位代码修改范围，待修改的类和方法是明確的。这就要求程序开发中需要将业务流程与具体实现进行分离，代码逻辑结构划分清晰。业务流程是抽象的，如果将抽象的业务处理融合在大篇幅的代码之中，一旦需求改变，整个代码都要修改，无疑增大了工作量。封装变化是可控性代码的重要特征，在将需求转变成设计方案的过程中，要分析出哪些是变化的，哪些是不变的，并对变化的部分进行封装。在对需求和现有代码全面掌握的基础上，明确影响范围，有效应对需求改变导致的代码修改。

（2）扩展和修改的代码内容可量测。具有良好可控性的代码，遇用户新增或改变需求，在确定修改范围之后，可以预估出需扩展和修改的代码量，即具有代码的可量测性。程序代码除具有较好的可扩展性和可维护性，还需要将这种可能性量化，至少评估出按照“堆砌原则”需要增加或修改的代码量。这种可量测性是在第一步明确修改范围的基础上，继续对代码修改的内容作出评估，提出将代码维护工作可度量化，并能够预测可能发生的变化。代码中应尽可能提高复用率，减少重复代码，避免硬编码。可控性要求将代码之间的耦合性降到最低，拒绝大段瀑布流式的编程实现。程序中具有“原子性”功能的实现是可抽离的，不依赖于业务逻辑和其它“原子性”功能，且这种实现的代码可以量化。可控性差的程序代码必然针对修改或扩展的代码量无法作出评估，不能给出具体的工作量，也不能实现对任务的合理分配，增加软件开发项目的进度管控风险。

（3） 所有的代码修改应在本层为止，否则就要变更设计。随着软件版本的演变，对代码进行修改或调整是不可避免的。可控性程序由结构化的代码构成，即代码具有明显的层次划分。代码最基础的层次是类级别，最分明的层次是包（命名空间）级别。软件系统角度上的层次划分往往是多级别，并不局限于包或者类，层次划分可以虚拟化。每个层次是具有独立功能实现类的集合，各层次之间应存在较为清晰的界限。可控化更加注重总体设计与细节设计之间的模式转换，强调设计先行的原则。软件架构设计与模块设计应充分考虑功能的集合特征，不同层次之间的接口调用应遵循简洁高效的原则。程序细节设计或实现，可以参考现有设计模式，但不拘泥于设计模式，以方法产生的实际效果为主。设计要充分考虑层次划分的边界，无论自上而下还是自下而上，所有的修改应在本层内完成，避免跨层修改，减小代码波及的范围。如因需求改变，出现了多层代码都需要修改，就要考虑原有设计是否合理，然后根据具体情况调整设计方案。

3改进措施

（1）注重顶层设计方案落地。顶层设计是在充分了解用户需求的基础上，结合目前产品现状，给出的最佳解决方案，具有一定的前瞻性。开发核心人员应全程参与产品的设计阶段，以确保对设计方案的理解无偏差。一方面加强设计方案的贯通，让开发人员领会架构的意图；另一方面加强对实现过程的管控，将方案落到实处。开发团队应贯彻顶层设计的思想和解决方法，并将总体设计方案落实到代码实现中。

（2）规范程序中间设计环节。从总体设计方案衍生出来的设计都可以称为中间设计，如从总体设计到详细设计。这涉及到一些模式转换，是一个承上启下的过程。中间设计需要总体设计方案人员和开发人员参与，并通过相关人员评审，确保中间设计环节不偏离顶层设计。

（3）提高开发人员技能水平。人才是企业的核心竞争力，代码的问题归根到底还是人的问题。通过技能培训或交流，与产品开发相结合，提高开发人员基础水平。经验丰富的程序员要发揮带动作用，促进其他开发人员不断进步。如今技术革新周期不断缩短，研发团队中要形成学习的氛围，勇于尝试新技术、新方法。

（4）加强程序代码质量检查。代码质量检查应列为软件产品测试的组成部分，其中代码可控性是软件产品质量检查的重要参考指标。代码质量初步检查可以使用工具实现自动化或半自动化，如CheckStyle、PMD、FindBugs等[6]。代码管理人员需要对代码进行阶段性质检，降低代码中的潜在风险，保证每个迭代阶段提交到版本库中的代码质量。