关于系统升级的讨论

 

我个人认为系统升级应在不改变现有好的数据库设计和架构设计的基础上，来升级架构设计，从而完善系统。

   在实际工作中,我们开发和维护的人员很有可能不是同一个人,维护人员不熟悉原开发人员的业务设计意图,因此维护人员很可能以某种破坏原始设计的意图和设计框架的方式将新功能加进去.由于这些改动是以累积的方式进行的,所以维护人员也不可能也无法形成自己的设计意图,而只能是一些东拼西凑的权宜之计,这样的破坏式的增强功能越来越多,以至于最后原始的设计已经被这些没有总体考虑和固定规律的东西取代,系统就这样.....
系统的业务和性能,功能等肯定是会变的,我们设计的系统应该为日后的变化留出足够的空间.
 
这几天我想了一下，认为我们的系统整体上其实已经很好了,但在以下几方面做的不好：

1.复用率低。几乎每个功能到另一个项目中都得重新修改（但是基本要实现的功能都差不多）。
    建议可以将很多相同的基础的功能抽象出来，如再有特殊需求的时候再继承基础功能,再写其新增方法，增加了其扩展性。
    例如张立胜统计出的菜单,不分渠道,但后台应抽象实现出其基本功能(所谓的基础模型),然后再根据不同的需求增加不同的功能,实现了其可扩展性.
 
    一个依赖抽象层的系统在开发过程中，难免会在抽象层和实现层中改来改去，工作量甚至会成倍的增加,这样的系统在后期的维护与再次开发中的好处却是明显的，要做的改动会少很多,也会更容易些.如果使用接口,通过接口耦合的系统有更好的整体性和可维护性，可扩展性,但类结构图的复杂度就大大增加,本身我们系统就没这方面经验,人员开发经验就更少了,如果在后期出现问题,既改接口又改代码无疑是灾难,所以不建议使用接口,对我们的系统而言更适合使用抽象类.

2.黏度过高。一个方法中写了太多的处理(几千行)，导致查找修改工作烦琐，效率下降，灵活性差。
    建议将业务逻辑分开处理，分别放到不同的方法中，尽量做到功能单一，实现“高内聚、低耦合”,便于修改某个业务逻辑,而不影响其它逻辑,体现出一个系统的灵活性。