目前在进行的Boss开工改版，需求版本比较大，涉及到企业入网及配置、企业结算、充值分账、签约、下发、发票开具等各个环节，同时要兼容现有系统里存量客户和交易不受影响。虽然拆分成3次小迭代，不过每次迭代的开发任务也同样不容小觑。

因此，必要要从更高更全面的角度来俯视系统，做好设计工作。如下是在公司内部wiki上记录的一些开发设计文档。

 

 

如下，分享其中的一个重构案例。

 

 

emax_base库发票相关表表名调整

§ 背景

1.  随着bosskg系统的需求迭代和整合升级，测试库emax_base库的数据表也逐渐增多。发票业务当前涉及到6张数据表，这些表的表名都是以默认的前缀emax_开头，分散在数据库里不方便查找。
2.  新的bosskg改版需求，发票管理又要加表，如果还是以emax_开头，技术债务将越欠越多，留给日后调整的成本更大。
3.  除了前缀以外，这些发票涉及到的表里，有几张表的表名并不能清晰描述其领域功能。比如emax_bill_info_config，其实是我司开票方title信息配置；再比如emax_bill_info，其实是个人用户的开票记录。表名定义不清晰的另一个后果是：我在近期代码走查时竟然发现，竟然出现了BillInfo相关的操作方法，一部分在BillInfoService.java里，另一部分却跑到BillService.java里了。这也许不能完全归咎于当事人的粗心，更重要的因素，也许正是这些易混淆的表名导致的。

当断不断必受其乱 +  Do first thing first ==》是时候重构了！

 

§ 重构调整策略

1.  重构范围控制---通常来说，许多同学对重构是敬而远之的，一是担心对业务了解不透彻出现遗漏，二是惧怕出问题而承担责任，多一事不如少一事，再者是觉得能凑合就凑合，甚至会认为在重构代码上花时间并不值得，不如去学学其他新鲜的技术，学学Python，学学算法，学学架构设计。——这次改动涉及到6张表的业务操作，显然非小事，涉及到表/字段、service/pojo、数据迁移。所以，有效控制改动范围，是个关键。基于这些考虑，这次调整呢，先从大方向上着手，只改表名。
2.  为了避免干扰大家开发，测试库emax_base已经把旧有表删掉。如果想看，可在test_emax_base库查。

 

§ 表名调整

-- 开票相关表重命名了，执行下面语句查看新旧表名对应关系（生产需要迁移数据） SELECT table_name 表名,TABLE_COMMENT '表注解' FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = 'test_emax_base' AND (table_name LIKE '%bill%' OR table_name LIKE 'inv%')

 

 

§ 程序调整

 

 

赞成为第一个赞同者

 

标签：重构,流畅,emax,代码,base,发票,表名,table
来源： https://www.cnblogs.com/buguge/p/14806153.html