让不难降为简单

商业软件开发的过程，一般来说是个产品定制的过程，

这与一向接受标准化、量产化教育的编码工作从业者而言，这不得不说是工作中遇上的最大的矛盾（以下简称矛盾），

即使这些定制化的开发内容，绝大部分工作都并不具备多少难度。

而这个矛盾也是导致不少商业软件开发成本不同程度上涨的根源（

  成本上涨，是基于一些非常原始而大局上的的成本估计，

  这个成本各式各样，包括人力、时间、debug等，详细不啰嗦，您懂的）

于是，商业软件开发的成本控制的本质，就在于解决矛盾的程度，因此，比起技术上的问题，这个命题更倾向于工程学上的问题。

在这里，我们先假设2个前提：

1、需求已经处于不可能推翻任何细节的情况，只有需求方可以对需求做任意增删改，实现人员只需要按需求实现；

2、整体需求和每一个细节，都不存在任意技术障碍，手上已经有足够的工具和环境去实现。

然后，按照一般的小团队工作流程（或者在稍大规模的团队中也是这样），我们会：

1·按需求块划分，指定各个块的实现负责人；

2·读需求；

3·编码；

4·debug循环；

5·交付。

（请原谅上面说的太随意，也不一定每个团队都是这样的流程，但是在这里用太多术语也没多大意思）

这个看似简单的流程，其实就是一个定制化和标准化的缓冲（互相妥协）结果，我个人理解为：

1·拆分定制化的需求，方便进入实现流程；

2·定制化的需求分析，通过现有工具和技术，指定实施方案；

3·通过基于量产化的技术和标准，实现需求；

4·需求校对；

5·需求完全实现。

而冲突最激烈的地方，一般会认为是2~4的过程，但是从我个人角度来看，1已经是这个矛盾冲突的开始了，

因为，我们从一开始就没有明确界定好，到底是彻底标准化，还是彻底定制化，而仅从成本的角度看，彻底定制化显然不是接下来的选择，

于是，接下来的解决方案，就从彻底标准化方向来探讨（这里先不讨论需求规模，见谅）：

1·读需求，统筹性地重构需求（不改变任意需求内容），例如让需求的文档结构变得更适合人阅读和分析，

   并且容易与制作过程、验收过程结合，当然，进一步上，可以抽象出需求间的关联性和共性；

2·存、取需求，把完成重构的需求，保存到需求历史中，进一步上，可以与历史需求进行校对，继续抽取关联性和共性；

3·在重构完毕的需求基础上再分配任务；

4·debug循环；

5·交付。

用例：

在某一个版本里，需求有：

1·增加一个数据管理系统，该系统的数据和以往数据表都不兼容，需要独立制作，该系统带有新界面；

2·对某一个已有界面进行重新改版；

3·对某个已有数据流程插入新的数据项和数据存取需求，该操作会导致流程上较大幅度的更改，并需要更改表结构和传输结构；

4·对某几个已有界面的细节调整；

5·对某几个已有计算公式的修改。

这个时候，我们不必急着把上面的条目划分给哪几个人去负责，而是把这些条目及其细节内容展开，我们可能会发现：

·3的修改结果或许刚好和1的数据结构相似（甚至相同）；

·4的调整内容里，或许会和2共享一些控件、布局；

·3的新流程和已有的某个系统（已完成的需求）流程非常类似；

·5的几个计算公式让本来一行的函数膨胀成几行，而且几个公式都很有个性，无法公用；

·4的需求上 ‘看起来’ 微小的改动，里面需要进行大大小小的手术；

·。。。

然后，对该需求进行较深度重构的处理后，用例中的需求则会化为另一种表达方式（这也是重构的目标之一）

·添加/修改出 一种数据处理流程，包括数据表、数据结构、协议的更改，

 至于具体的数据如何，可以根据需求细节再填充；

·一些界面需要使用一类新的布局、控件，这些布局需要制作/修改出来，控件需要生成；

·公式处理模块需要添加新的成员，原本嵌在其它流程代码里面的公式，现在要改为从公式模块取用；

·。。。

是的，这虽然是我随便杜撰出来的情况，但是实际工作过程中，何止万千，

如果开发团队在工作过程中，不对需求进行较为深度的加工，而且直接按照条目分派任务，

上面这些情况只会引起一次次的重复劳动、重复思考，更甚至是重复代码，重复的bug。

虽然在各种 ‘重复’ 的锻炼下来，会让开发人员变得更勤快，更谨慎；

而在这里我提倡的模式，或许会让大部分开发人员成为正式的流水线上的工人，

更可能这只是一种理想化模式。