走出面向对象编程的沼泽—在SOA中使用WebSphere Adapter[3] SOA三层构架
关键字：面向对象 编程 SOA
逐渐陷入沼泽
需求变化
这天早晨，Peter一到公司便被项目经理叫到了办公室。原来，项目的需求有点变化，Peter负责的那个子模块的功能需要增加，不仅要实现对应用系统A的若干数据库表的数据写入，还要能够完成相应的修改和删除操作。在Peter看来，增加这些功能简直是小菜一碟，自己以前的实现代码很多地方很重用，只需稍微修改一下便可搞定。于是，他花了一个下午，在原来的代码基础上增加了几个方法便搞定了。
在接下来的几天里，Peter所负责的子模块不断地有新的功能需求加入进来，随着功能不断增多，其实现的代码量自然也是不断地膨胀，已经由最初的200行左右增加到了5000行左右。
随着代码的日益臃肿，一些代码的bug开始逐渐出现了，并且有逐渐增长的趋势。这让Peter开始感到有些隐隐的不安。
渐入困境
第天一大早，项目的测试人员便跑过来找Peter。原来，客户对系统的整体性能做了一个初步的测试，而测试结果非常不令人满意。测试人员经过仔细分析后发现，Peter负责的那个子模块是整个系统性能低下的罪魁祸首。这天Peter工作到半夜，终于找到了其中的原因。原来，他在每次数据库操作之前都要创建数据库连接，操作过后再关闭该连接，频繁的数据库连接新建和关闭操作造成了系统性能的大幅下降。Peter决定把数据库连接的管理功能抽取出来，采用连接池机制，这样可以实现数据库连接的共享，避免频繁的新建和关闭操作，从而解决系统的性能问题。在Peter对代码做了一番修改之后，性能问题是解决了，可是测试人员很快发现原来的一些正常功能受到了破坏。
事情似乎进入了一个恶性循环，解决一个现有的问题时稍不小心就会引起更多新的问题。
致命打击
就在Peter已经忙得焦头烂额时，一个噩耗传来：项目需求又有变化，应用系统A的数据表结构要进行调整，而且需要增加对另外几个数据表的访问。这意味着Peter原来的实现代码大部分需要重写。这让Peter几乎绝望，项目目前已经接近尾声，他很清楚现在做这样大规模的代码改动不仅时间上不允许，而且风险很大。
Peter濒临崩溃，整个项目也将面临失败的危险。
文章来源于领测软件测试网 https://www.ltesting.net/
