标签：重构 流畅 emax 代码 base 发票 表名 table
目前在进行的Boss开工改版，需求版本比较大，涉及到企业入网及配置、企业结算、充值分账、签约、下发、发票开具等各个环节，同时要兼容现有系统里存量客户和交易不受影响。虽然拆分成3次小迭代，不过每次迭代的开发任务也同样不容小觑。
因此，必要要从更高更全面的角度来俯视系统，做好设计工作。如下是在公司内部wiki上记录的一些开发设计文档。
如下，分享其中的一个重构案例。
emax_base库发票相关表表名调整
§ 背景
- 随着bosskg系统的需求迭代和整合升级，测试库emax_base库的数据表也逐渐增多。发票业务当前涉及到6张数据表，这些表的表名都是以默认的前缀emax_开头，分散在数据库里不方便查找。
- 新的bosskg改版需求，发票管理又要加表，如果还是以emax_开头，技术债务将越欠越多，留给日后调整的成本更大。
- 除了前缀以外，这些发票涉及到的表里，有几张表的表名并不能清晰描述其领域功能。比如emax_bill_info_config，其实是我司开票方title信息配置；再比如emax_bill_info，其实是个人用户的开票记录。表名定义不清晰的另一个后果是：我在近期代码走查时竟然发现，竟然出现了BillInfo相关的操作方法，一部分在BillInfoService.java里，另一部分却跑到BillService.java里了。这也许不能完全归咎于当事人的粗心，更重要的因素，也许正是这些易混淆的表名导致的。
当断不断必受其乱 + Do first thing first ==》是时候重构了！
§ 重构调整策略
- 重构范围控制---通常来说，许多同学对重构是敬而远之的，一是担心对业务了解不透彻出现遗漏，二是惧怕出问题而承担责任，多一事不如少一事，再者是觉得能凑合就凑合，甚至会认为在重构代码上花时间并不值得，不如去学学其他新鲜的技术，学学Python，学学算法，学学架构设计。——这次改动涉及到6张表的业务操作，显然非小事，涉及到表/字段、service/pojo、数据迁移。所以，有效控制改动范围，是个关键。基于这些考虑，这次调整呢，先从大方向上着手，只改表名。
- 为了避免干扰大家开发，测试库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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。