信息系统重构相关问题探索

​        摘要：计算机系统的质量除了产品设计的初衷大势以外最重要的是代码质量。代码质量高低是计算机系统与时俱进的根本，作者在代码重构时对老旧代码设计和代码复用上痛感到业务代码边界得模糊而导致重构艰难。作者试图通过业务代码重构实践来摸索一套普适的编码规范。概括来说为：基础设施独立聚合，业务实现抽离，业务调用聚合单向注入，业务调用纵向规则。

      关键词：数据库；业务划分；项目设计；业务纵向规则

​      随着时代的发展，计算机硬软件都在不断发展。老旧的软件系统或由于无法满足用户的增长，或由于编程语言的落伍或淘汰不得不进行整体架构的全面升级。由于老旧代码往往没有规范或者规范性不强，开发人员常常以实现业务功能为首要目的，加之缺乏整体规划意识。老旧代码往往成为软件公司的烫手山芋。

        作者通过对以往系统的重构经历的回顾，发现老旧系统的主要问题有如下几项。

         1.数据库设计不规范。很多老旧系统由于缺乏整体规划，往往依靠于项目的初始代码进行扩充。数据库也是一样，数据库的第一张表往往变成决定了数据库设计的导向。总结来说旧系统的数据库和字段命名命名、类型和字段长度、索引、存储过程和视图都会称为系统改造的痛点。数据库设计上追求的是系统的速度和可扩展性，由于很多系统往往是不断兼容新业务，所以在表设计上往往是随时添加字段，这就造成数据库中存在一些零碎的脏数据，脏数据对系统升级提出了很大限制，必须要和老代码逻辑一致。在数据字段命名上由于老项目往往以起始代码作为模板，所以字段命名上可能种下了不好影响。日久天长在不同的开发人员的维护下产生不同的命名风格。存储过程和视图在老系统的经常存在，在系统升级时，也要特别注意将其提前进行剥离。很多旧表在字段设计上不科学，尤其是字段长度和字段类型，过长的字段长度没有什么意义还徒增计算机的总线资源，数据类型选择不当，导致重构时需要不断类型转化。

      2.业务边界不清晰，在经典的计算机系统中提倡高内聚，低耦合。高内聚要求将业务限制在合理的领域内，通过提供开放的接口供其他业务调用，这样做的目的就是低耦合。在作者所经历的软件系统中，一般都是业务纵向互不干扰，经典的模式就是接口-业务逻辑-数据库表一条线，往往将操作同一张表的所有操作写到相同的业务层，对于需要跨表实现的业务往往将需要的业务实体通过接口注入，但是在很多老系统中，往往业务边界划分不清晰，很多在业务层实现的功能却出现在接口层。原本业务A负责的业务可能写在业务B，除此之外对数据的校验随处可见，没有统一的规范。这些都导致在系统重构时要保障与原有代码保持一致，不能有过多的变动。除此之外对外接口已经定死，接口变动往往需要调查被调用方的使用情况，所以对于系统的重构从里到外都会被限制住。这也是开发人员不愿意触碰老项目的原因所在。

       3.代码混乱，由于开发人员的更新换代。一套系统越来越复杂，很多已经废除的代码出现在正式代码上，增加了代码重构的影响因素和时间成本。由于老旧系统时间跨度长，编程风格和使用的框架和技术都脱离现在，很多开发人员由于学习成本因素和新功能的开发需求因素的影响而对老旧系统产生排斥心理，这种心理往往导致开发人员以解决问题为导向，而对于原有代码的优化工作放任自流，日久天长，老旧系统就成为众矢之的压力山大。

       对于上述问题，作者通过分析主要总结如下几个解决方法和规范。在数据库设计上要有明确的规范，避免使用视图，存储过程，字段命名要明确，能够让开发人员界定字段所代表的业务属性，避免适用byte等需要转化得数据类型，对于字段长度要预订在合理的范围内，不要对小数据内容字段设置过长的存储空间。在表设计上要预留足够的字段以备业务开发需要。数据库是系统的核心，如果设计的不好直接决定系统以后的各项能力，如果数据迁移，往往需要面对各种潜在的问题。所以最好是一步到位。

        在业务边界上，我们可以定义确定的规范，这往往需求有经验的开发人员去制定，作者通过对之前参与的系统的分析主要表达以下观点，第一在业务上依然保持纵向规则，相同领域的接口编写在相同的接口类中，接口层对用户上送的数据进行检验保证传入业务层聚合层的数据都是合理规范的，在业务聚合层不允许通过其他业务接口注入业务实体。只能注入数据库接口层，保障业务调用链的纵向性，为了实现原来需要注入才能实现的功能，我们需要将原来的业务层提炼为领域层，领域层是处理业务的核心。业务聚合层在业务实现上需要实例化一个领域实体，并将数据库接口实体作为参数传入，领域层完成功能将结果返回。对于调用外围系统的业务，需要提炼出来单独成包，并在业务聚合层进行注入。通过上述过程即刻保障业务的纵向性不变，业务聚合，数据库类型切换对业务无污染。业务条理清晰的功效。

       规范的设置需要开发人员去落实执行，而没有被认可的说辞对于系统实现来说也无法做到始终如一，所以在规则确定之后往往需要向开发人员说明为什么要这么做以及这样做的优点，同时做到不定时代码审核。只有真正将系统业务做到极致，才能吸引开发人员跟随设计人员的思路去优化代码，从而让老代码不再成为负担，反而成为组织的财富。同时也将是普通开发人员不断进步的积石。