[关闭]
@liuhui0803 2016-07-10T14:27:32.000000Z 字数 4937 阅读 2072

编写可维护的配置代码

文化和方法 DevOps 开发 配置管理 维护

摘要：

本文探讨了如何对“配置的味道”进行分类，配置的实现可分为13种味道，配置的设计可分为11种味道。此外本文通过几个范例介绍了配置的不同味道与相应的重构和优化措施，解释了这些因素对项目质量的影响，同时提供了几个能发现这类味道的工具。

正文：

主要结论

  • 像对待软件代码那样对待你的基础结构配置。
  • 配置代码需要避免出现“味道”，以及味道的不同类型。
  • 需要注意不同粒度环境（例如实现和设计）中配置可能出现的“味道”。
  • 可以在Puppet配置中使用Puppet-lint和Puppeteer等工具发现配置设计和实现过程中的味道。
  • 配置的味道会对项目质量产生极大影响。

基础结构即代码（IaC）是一种通过代码指定计算系统配置，实现自动化系统部署，并通过传统软件工程方法管理系统配置的实践。例如，某个包含大量节点的服务器场可能使用了不同硬件配置和不同的软件包要求，此时即可使用诸如Puppet、Chef、CFEngine，或Ansible等配置管理语言进行定义，无需人工介入自动进行部署。

IaC范式将基础结构、代码，以及用于管理基础结构的工具和服务以一种软件系统来看待。因此IaC实践会将配置代码视作与生产代码类似的产物，并对其应用传统的软件工程实践，例如针对配置代码进行的审查、测试、版本控制。

在传统软件工程方法中，为了编写可维护代码并实现较高的设计质量，通常需要做很多工作。与生产代码类似，如果对配置代码所做的改动不够用心或不妥善，配置代码很快也会变得不可维护。

本文中我们定义了配置的味道，并对不同“味道”进行了分类。

配置的味道

我们对“配置的味道”定义如下：

配置的味道是指不符合最佳实践要求，并有可能对程序质量产生不利影响的配置程序或脚本所具备的特征。

在传统的软件工程实践中，取决于抽象的颗粒性，以及产生的位置和影响，糟糕的味道可分为实现（或代码）的味道以及设计的味道。同理，配置的味道也可以分类为实现配置的味道，设计配置的味道，记录配置的味道等。本文将主要介绍实现配置的味道和设计配置的味道这两个主要类别。

实现配置的味道

实现配置的味道实际上是一种有关质量的问题，例如配置代码中的命名约定、风格、格式、缺陷。下文我们列出了各种实现配置时的味道和简要的介绍。

  1. 缺少预设条件（Default Case）：在case或selector陈述中缺乏预设条件。
  2. 命名约定不一致：所用命名约定与推荐的命名约定不符。
  3. 复杂表达式：程序包含难以理解的复杂表达式。
  4. 重复实体：配置代码中存在重复的哈希键或重复的参数。
  5. 属性错位：资源或类中的属性没有使用建议的顺序（例如强制属性应先于可选属性指定）。
  6. 不合理的对齐：代码对齐不合理（例如在资源声明中使用箭头）或使用了制表符。
  7. 无效的特性值：特性或属性使用了无效的值（例如文件模式规定使用3位而非4位八进制值）。
  8. 任务不完整：代码中使用FIXME和TODO标记代表任务不完整。
  9. 使用不建议的语句：配置代码使用某些不建议使用的语句（例如“import”）。
  10. 使用不恰当的引号：错误使用单引号和双引号。例如布尔值无需使用引号，变量名不能用于单引号字符串。
  11. 长语句：代码包含（通常无法在一屏完整显示）的长语句。
  12. 条件不完整：使用“if..elsif”构造时不使用“else”子句作为结尾。
  13. 疏忽使用的变量：插入字符串的变量没有包含在大括号内。

一起用几段Puppet代码看看上述提到的实现配置的味道范例。

  1. if $version == ‘4.4’ or $version == ‘4.2’ or $version != ‘4.5’ or $version == ‘4.9’ or 
  2. $version == ‘5.0’{
  3.     case $::operatingsystem {              
  4.         'debian': {
  5.             apt::source { 'packages.dotdeb.org-repo.app':
  6.                 location          => 'http://repo.app.com/dotdeb/',
  7.                 release           => $::lsbdistcodename,
  8.                 repos              => 'all',
  9. 	   include_src           => true        
  10.                 }
  11.             }
  12.         }
  13.     }
  14.     elsif $version in ['33', '3.3'] {       
  15. }

上述代码片段中包含下列“味道”：

上述代码片段可以重构为下列内容：

  1. if $version in ['44', '4.2', '4.9', '5.0'] or $version != '4.5'{
  2.     case $::operatingsystem {              
  3.         'debian': {
  4.             apt::source { 'packages.dotdeb.org-repo.app':
  5.                 location => 'http://repo.app.com/dotdeb/',
  6.                 release	 => $::lsbdistcodename,
  7.                 repos 	 => 'all',
  8.                 include_src 	=> true
  9.                 }
  10.             }
  11.         default:{}
  12.         }
  13.     }
  14.     elsif $version in ['33', '3.3'] {        
  15.     }
  16.     else {
  17.     }

设计配置的味道

设计配置的味道意味着模块的设计或配置项目的结构存在质量问题。

1.多方面抽象（Multifaceted Abstraction）：每个抽象（例如每个资源、类、‘定义’或模块）需要设计为仅代表软件某一方面的特性。换句话说，每个抽象都应遵守单一职责这个原则。如果抽象的元素不具备内聚性，多方面抽象可能会遇到问题。

这个味道可能会以下列两种形式出现：

2.不必要的属性：一个类、‘定义’，或模块必须包含指定所需系统特性的声明或语句。从空的类、‘定义’，或模块中可以闻到不必要属性这一味道，需要将其移除。

3.**命令式抽象：**Puppet的本质是陈述式的。命令式语句（例如“exec”）的出现违背了语言的本意。包含大量命令式语句的抽象可以闻到命令式抽象的味道。

4.缺少抽象：如果封装在诸如类或‘定义’等抽象中，资源声明和语句的使用和重用会变得很容易。如果资源和语言元素的声明和使用没有将其封装到抽象中，模块就能闻到缺少抽象的味道。

5.模块化程度不足：如果抽象规模足够大或足够复杂，并可进一步进行模块化，此时该抽象将能闻到这个味道。这个味道体现为下列集中形式：

6.重复块：重复语句块的数量如果超出某一阈值，意味着可能缺少适当的抽象定义。此时包含这种重复块的模块就能闻到重复块的味道。

7.层次结构不完整：继承的使用必须限制在同一个模块中。如果跨越命名空间进行继承（不遵守“is-a”关系）就能闻到这个味道。

8.非结构化模块：一个配置代码库中的每个模块必须具备妥善定义且一致的模块结构。推荐使用的模块结构如下：

Ad-hoc结构的代码库如果存在非结构化模块这一问题会影响代码库的可理解性和可预测性。

9.致密结构：如果配置代码的代码库存在过度密集的依赖性且不具备任何特定结构就能闻到这个味道。

10.缺乏封装：如果节点定义或ENC（外部节点分类器）声明了一系列供定义中包含的类使用的全局变量，就能闻到这个味道。

11.削弱模块化：每个模块必须尽量做到高内聚低耦合，如果模块高耦合低内聚就能闻到这个味道。

一起用几个例子看看上述提到的设计配置的味道。

范例1：请考虑下列代码片段（Puppet）。

  1. #Contents of file package.pp
  2. class package::web {
  3.     …
  4. }
  5. class package::mail {
  6.     …
  7. }
  8. class package::environment {
  9.     …
  10. }
  11. class package::user {
  12.     …
  13. }

上述片段显示了一个包含四个类定义的文件。这种一个文件包含多个定义的做法违反了单一职责这个原则，并导致产生多方面抽象的味道。

将每个类定义放在独立文件中，即可重构上述代码片段。

范例2：请考虑下列Puppet代码片段。

  1. class web {
  2.     exec { ‘hadoop-yarn’:
  3.         …
  4.     }
  5.     exec { ‘apache-util-set’:
  6.         …
  7.     }
  8.     exec { ‘smail-invoke’:
  9.         …
  10.     }
  11.     exec { ‘postfix-set’:
  12.         …
  13.     }
  14. }

Puppet是一种声明性语言，因此我们需要指定自己到底要实现“什么”，而非指定“如何”实现。然而肆意使用“exec”语句使其变为命令式代码，这样做违背了语言的用途。这样的代码可以闻到命令式抽象这一设计配置的味道。

使用Puppet的语言结构重新指定“what”部分并取代“exec”即可重构上述代码。

范例3：假设一个包含配置代码的代码库中（代码库内不同模块之间的）依赖图形成了一种致密复杂的结构。由于致密、复杂的结构所导致的脆弱性，这样的代码库很容易出现大量Bug。在我们的分类中，我们认为这样的代码库可以闻到致密结构的设计配置味道。

对于Puppet代码库，需要尽量确保每个模块都只有很少量的依赖（完全没有最好），大部分情况下可通过独立模块消除这种味道。

“味道”的影响

有人可能会说，上述味道本质上其实非常简单，它们对配置项目或人员的影响微乎其微。

不同味道会对配置项目产生不同影响。实际上少数一两个味道可能没什么大不了的，但如果某个项目充满各种不同味道，组合在一起可能会对可维护性产生极大的影响。这个问题其实类似于压倒骆驼的最后一根稻草。很难相信一根稻草就能压倒骆驼，然而如果骆驼背上已经放了很多稻草，骆驼的主人决定继续一根一根增加稻草时，可能随后增加的某根稻草就会把骆驼彻底压倒。每种味道就如同一根稻草，考虑到其他味道的存在，最终可能产生严重的后果。

检查配置味道的工具

为了检测是否存在上文提到的设计配置味道，我们开发了一个名为Puppeteer的工具，这是一款使用Python编写的开源工具。若要检测实现配置的味道，则可使用Puppet-Lint。

我们还进行了一个详细的研究，共分析了4621个包含Puppet代码的开源代码库，希望从中找出与配置味道有关的信息。详细结果请参阅这篇论文，本文已提交至2016年度Mining Software Repositories大会。

关于本文的作者

此处输入图片的描述
Tushar Sharma目前是雅典经济与商业大学的研究员。之前他曾在位于印度班加罗尔的西门子研究和技术中心就职七年。他的职业生涯主要从事与软件设计、重构、代码和设计质量、技术债务、变革影响分析，以及基础结构即代码（IaC）有关的工作。他与人合作撰写了包括《重构软件设计的味道：管理技术债》在内的三本书。他是IEEE资深成员。

此处输入图片的描述
Marios Fragkoulis目前正在雅典经济与商业大学管理科学与技术系Diomidis Spinellis教授领导下攻读数据呈现、查询和管理领域的博士学位。他曾在伦敦帝国学院计算机部考取理科硕士学位，并在雅典经济与商业大学管理科学与技术系以优异成绩取得理学士学位。2015年他曾兼职在OTE S.A.担任基础结构运营工程师，并在希腊GRNET S.A.担任软件工程师。他还开发了PiCO QL这一在线数据分析系统。

此处输入图片的描述
Diomidis Spinellis是希腊雅典经济与商业大学管理科学与技术系教授。他撰写过两本获奖图书《月度代码》和《代码质量：从开源的角度解读》，并已翻译为多种语言。在你读到本文的同时，他的新书《有效的调试：66种特殊的软件和系统调试方法》应该已经正式发布。他持有伦敦帝国学院软件工程硕士和计算机科学博士学位。Diomidis曾担任IEEE计算机学会理事会选任委员（2013–2015年），同时他也是ACM和IEEE的资深成员。2015年1月起他开始担任IEEE Software主编。

添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注