编程内功:业务逻辑抽象

用代码量衡量程序员的工作量大抵是世上最愚蠢的事了。

今天重构了一段年代久远的大约2000行的代码,目前剩下200行左右,这段代码的功用大致是这样的:

将一些数据,按照几个维度的规则填充到另一个表里面,数据和表里的数据可能是一对多的情况。

事例

规则有3个维度:一个优先级性质,数据类型,规则层次

老代码是如何组织的?

三个维度的规则下穷举所有情况,我看了一下数据库操作次数等性能层面较优秀,但可读性和维护性实在是差。

新的代码是如何组织的?

仔细看三个维度其实其中优先级性质,规则层次这两个用来负责校验这条数据是否要插入到表里,数据类型确定插入哪些字段,这样代码就分为两个部分,首先判断是否要插入,然后根据情况做数据的插入动作。

这样就较完美的达成了代码的小模块内的重用,并且能够较好的自解释其运行逻辑。


所以我们之后在实现一个feature之前是否会有一个以上的方案,是否会从性能,可读性等方面在心中比较每个方案的优缺点在动手实现呢?
  • 2
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值