软件系统三大关切之可维护性Maintainability

众所周知，软件成本的主要开销并不是一开始的开发，而是持续不断的维护 – 修复bug，保持系统运转，调查failure，迁移到新的平台，针对新用例进行修改，偿还技术上的debts，以及增加新功能。

另外，更不幸的是，许多在软件系统上工作的人不喜欢维护所谓的legacy系统，这其中或许就包括修需其他人的错误，或是在过时的平台上工作，又或是强迫系统去做一些本就不能做的事情。每个legacy系统都以其自己的方式令人不快，并且因此很难给出处理这些问题的一般性建议。

然而，我们可以抱着以减轻维护过程中的痛苦并且避免我们自己创造出legacy系统的心态，己所不欲，勿施于人，去设计软件。为此，我们要特别注意软件系统的三个设计原则：

当然，嘴上说说多容易，哪有那么容易，不过我还是应该试着记在心里。

可操作性

我们经常说，好的运营经常可以规避糟糕或不完整的软件的限制，但好的软件也不能以操作运营的方式而可靠的工作。虽然运营中的一些方面应该做到自动化，但还是需要人在一开始时配置自动化并且使其正确运行。

运营团队对于软件系统的平稳运行是至关重要的。一个好的运营团队一般负责一下事务斌并且更多：

好的可操作性意味着制定简单的常规任务，允许运行团队关注在高价值的任务上。数据系统可以通过如下的方法使得常规任务：

简单性

小型软件项目可以具有令人愉悦的简单且富有表现力的代码，但是随着项目的扩大，它们通常变得非常复杂且难以理解。这种复杂性减慢了需要在系统上工作的每个人的速度，从而进一步增加了维护成本。陷入困境的软件项目有时被描述为big ball of mud。

可能存在复杂性的各种症状：状态空间的爆炸，模块的紧密耦合，依赖性的纠缠，命名和术语的不一致，旨在解决性能问题的黑客程序，处理其他地方问题的间接手段等等。

当复杂性使维护变得困难时，预算和时间表通常会超支。在复杂的软件中，进行更改时还存在引入错误的更大风险：当开发人员更难以理解和推理系统时，更容易忽略隐藏的假设，意外的结果和意外的交互。相反，降低复杂度可以大大提高软件的可维护性，因此简单性应该是我们构建的系统的主要目标。

使一个系统简单并不必须意味着降低它的功能性；它也意味着移除一些意外的复杂性。Moseley和Marks是这样将复杂性定义为意外的

并不是因为软件解决用户的问题而衍生的，而是由于实现时造成的

抽象是用于消除意外复杂性的最佳工具之一。好的抽象可以在干净，易于理解的外观后面隐藏大量实现细节。好的抽象也可以用于各种不同的应用程序。这种重用不仅比多次重新实现类似的东西更有效，而且还可以带来更高质量的软件，因为抽象组件的改进使使用它的所有应用程序受益。

例如，高级编程语言是隐藏机器代码，CPU寄存器和系统调用的抽象。 SQL是一种抽象，它隐藏了复杂的磁盘和内存中的数据结构，来自其他客户端的并发请求以及崩溃后的不一致。当然，当使用高级语言编程时，我们仍在使用机器代码。我们只是不直接使用它，因为编程语言抽象使我们不必去考虑它。

但是，很难找到好的抽象。在分布式系统领域，尽管有很多好的算法，但是我们如何将它们打包成抽象来帮助我们将系统的复杂性保持在可管理的水平上还不清楚。

进化性

你的系统需求永远保持不变是极其不可能的。你新学到的知识，先前未预测到的用例的出现，业务优先级的变化，用户需要新的功能，新平台对老平台的替换，法规的更改，系统的增长强制架构的改变等等，它们都有可能处于不断变化之中。

在组织过程方面，敏捷工作模式提供了适应变化的框架。敏捷社区还开发了技术工具和模式，这些工具和模式在频繁变化的环境中开发软件时很有用，例如测试驱动开发（TDD）和重构

这些敏捷技术的大多数讨论都集中在相当小的本地规模（同一应用程序中的几个源代码文件）上。

你修改一个数据系统并且使之适应不断更改的需求的轻易度，是与它的简单性以及抽象紧密关联的。

简单易于理解的系统往往比复杂系统更容易修改。

但因为这是一个很重要的想法，所以在数据系统级别我们用一个不同词evovabolity可进化性来指待敏捷。

来源：吃泡菜的鱼