一个失败的软件开发管理案例

前段时间受到一个朋友的邀请，参观并考察了他公司的开发管理，并向我陈述了现在的管理困境：

1. 软件版本多，不同的软件版本使用了不同的架构方案。目前存在四个版本，三个架构方案。

2. 不同的软件版本共用了业务模块的代码，但是代码里却没有实现软件版本的管理。如果有某个客户需要修改某个业务模块，开发人员要先检查客户的业务模块运行版本，然后再从代码管理工具里拉取这个版本出来，独立为该客户的业务模块版本。万一这个业务模块的基础版本发现了bug，这时需要

    a.修复基础业务模块，

    b.修复客户的独立出来的业务模块。

看出问题来了吗？我们如何确定这个bug发生在基础业务模块代码的哪个版本上？如果独立出来的客户业务模块版本很多（有多个客户独立出来了），我们如何确定这个bug的影响范围？根本没有办法取确定，非要确定影响范围，那就要先确定这个bug是在哪个历史版本开始出现的，然后需要一一检查客户的版本是否在这个历史版本之后，如果是那就需要修复。这个需要耗费的工时随着客户规模的变大，难度也就随着变大。

我不明白我的朋友他为什么不要求开发在代码里管理软件版本，以及客制化功能。我们在开发中会遇到判断操作系统版本，或者浏览器版本的情况。管理自身公司的软件版本也是一个道理。如果没有版本这个概念，公司系统就很难标准化，基本是一个客户一套代码。如果多个客户有类似的需求，我们就要分别为这些客户来实现，如果是一个新功能，我们可以简单的复制拷贝代码来实现。如果是一个历史比较长的功能呢？这个功能可能影响其他模块或者受其他模块影响呢？是不是又要花时间去理清楚这里面的逻辑。如果实现了产品版本、客户客制化的统一管理，我们在没有变更开发工具的情况下，其实可以使用一份代码就管理了产品的所有版本及客制化。这样开发人员在管理代码版本时也不用那么痛苦了。

这个公司的开发还存在以下问题：

1.过度拆分业务模块，导致需要管理的代码模块过多。同一个业务模块里，分出了响应用户操作的不同模块（这些模块采用dll独立实现），随着用户的操作，系统可能需要多次反复载入dll来执行相关业务逻辑。

2.业务逻辑在客户端，数据库系统中都有存放，导致代码的管理难度再上一个台阶。数据库系统中存放业务逻辑代码有利有弊，有利的地方就是在不修改调用接口的前提下修改业务逻辑（也就不需要修改客户端的业务模块了），这样方便了实施人员做小的修改调整；坏处就是系统的业务逻辑代码分散在多端，管理起来很麻烦，而且很难代码复用；DBMS的存储过程也不容易调试及测试。

3.为了实现用户界面的输入控件动态化（也即用户可以自己定义用户界面的输入栏位，以及调整布局）这个目标，系统的客户端框架与数据库端紧密耦合在一起。也即这个软件系统是与特定的数据库系统DBMS捆绑在一起的。想换数据库系统就只有重写用户端的实现。因为用户界面是配置式的，也即每个客户的同名模块可能配置不一样，导致公司在行业领域并没有带来标准化的领导作用。无法体现

4.框架里填满了控制器的概念，开发人员向我解释说采用了MVC的概念。我询问及查看了部分实现。天啦，这哪里是MVC的概念实现，他们的开发框架中控制器实际上应该算用户界面数据控件的事件监听器(Listener)。用户界面采用了动态创建（也即从配置表读取）的实现。

面对这样的局面，我也有一种无力的感觉，不过还是给出我个人的建议：

1.将不同的技术架构的产品版本整合到一个架构里来（这里主要是指该公司每个产品版本对应了不同的技术架构，使用了不同的伪中间件技术，有DCOM，有socket，最后的版本又切换到另外一个中间件技术上了）。其实因为是伪中间层，也即中间层除了起一个连接数据库的作用外，没有其他功能，这应该是可以很好将其他版本的中间层更换到最后这个中间件技术上来的。只是因为技术人员在客户端的各个模块代码里直接使用中间件的组件，导致改造的话，花费的人力比较大而已。但是我认为这个改造很简单，只需要定义一个中间件代理，客户端模块调用中间件的地方改成调用中间件代理。这样改造后的好处就是不需要再保留多个不同产品版本的代码，而是可以可以整合在一起了。

2.在代码里明确产品版本的管理，不同的版本，我们可以通过面向对象技术的多态很容易就达到。代码管理起来也很轻松。