软件不软：需求变更与代码质量

 

软件并没有软到“橡皮泥”的程度，可以随意捏造；

“丑陋的代码”，往往产生在需求变更的过程中。

本文分3个部分讨论这些问题：

1.静态的软硬件划分

2.动态的软硬件划分

3. 需求变更与丑陋的代码

1.静态的软硬件划分

关于软件与硬件的“官方”标准定义是：

软件是一系列按照特定顺序组织的计算机数据和指令的集合。

硬件包括电脑中所有物理的零件，以此来区分它所包括或执行的数据和为硬件提供指令以完成任务的软件。

这是“狭义”的定义，实际上对于“广义”的系统，在一个特定的条件下，硬件是不能改变的部分；软件是可以改变的部分。

比如余世维经常举的酒店管理的例子中，在“酒店系统”中，在“特定成本”的约束下，硬件指酒店的基础设施，软件指酒店的管理。

现在是时候对应用开发领域中的软硬件重新划分了！

对于我们开发的应用系统（Application），软件是我们自己写的代码；硬件是什么呢？相对于我们写的代码，下列的东西是不能改变的，它们都是“硬件”：

主机：这个本来就是硬件:)

操作系统：通常的应用不会去改写操作系统；

数据库：我们可以在数据库上写具体的数据库应用，但是对于代码来说，数据库和数据库应用都是硬件；

应用服务器：通常的应用也不会去改写应用服务器；

框架：框架一旦设计好了，就不能轻易改变了；

代码库：一般来说我们只是调用。

别人的代码：在团队开发中，不同的人负责不同的模块/层。这个其实不是绝对的“硬”，通过沟通还是可以修改的，但肯定比修改自己的代码要困难。

这样划分下来，其实在一个应用系统中，真正属于“软件”（即我们可以改变）的部分，其实是很少的。

2.动态的软硬件划分

为什么要强调软件与硬件的划分呢？因为一个普遍存在的错误认识，不仅仅是客户，也包括相当多的开发人员，认为系统可以随意修改。其实这个观点是有问题的。正确的观点是“系统可以任意设计”。

对这个问题还可以从软硬件划分的角度来看。即代码在不同的阶段分属于软件和硬件。比如我们经过分析，设计，开发，测试等过程，产生了一组代码，满足了特定的需求；那么在需求变更的时候，这组代码就变成了不可改变的硬件，因为我们原有的功能还是需要的。

3.需求变更与丑陋的代码

其实在系统维护时看到的大部分“丑陋”的代码，都是在需求变更时产生的。这和看问题的角度不同有关系。需求变更时，我们是基于“已有代码”这个“硬件”环境来考虑问题，在这种特定的情况下，代码并不是那么丑陋；而系统维护时，我们是基于全部已有需求，从全局的角度看问题，这时所有的代码都被视为“软件”，有些代码就显得丑陋了。

4.解决之道

关于解决之道，没有列入摘要中，因为我也没有好办法。只能想到两点要注意的事情：

一是迭代开发，有时可能只是增加一个“小功能”，但是要充分考虑对整个系统的影响。迭代开放可以走完分析、设计、开发、测试的完整过程，尽量从全局考虑新功能，避免“局部优化”带来的影响。

二是重构，这个需要时间，在制订计划时增加1－2个重构的迭代步骤，进行“全局优化”。

更多更好的办法还希望大家交流讨论。