这么设计参数,新人不掉坑里才怪

最近遇到2个非常真实的案例,一个参数控制2种不同的业务,虽然业务有所关联,但是严格的来讲,又属于两种不同的业务,导致花费了不少时间去梳理与配置。这让我不得不思考一下如何设计参数防止新人踩坑。真实的案例,真实的感受。

案例一 开始时间 结束时间

2个业务A、B都有开始时间与结束时间,业务场景一【开始时间X,结束时间Y】使用业务A,其他时间使用业务B,业务场景二【开始时间X,结束时间Y】使用业务B,其他时间使用业务A。

如果设计参数的时候,仅设计2个参数开始时间与结束时间,还允许出现参数配置中出现开始时间大小结束时间的配置方式,的确,2个参数满足了业务配置。这块参数配置就像是人为挖了一个坑,一个简单的配置,变成了一个烧脑的配置。

做为新人来讲,做梦也难以猜到一个配置影响2个业务,还能配置成开始时间大于结束时间,这都不符合常理。这直接导致花费了许久的时间与读代码,还耗费了技术经理的时间,这对于项目的可维护性来讲,就是毁灭性的打击。

案例二 一个执行时间2个业务用

2个业务A、B,一个参数配置,业务A取执行时间的小时部分,每小时执行,业务B取小时与分钟,每天执行一次。比如执行时间18:10,那业务A则每个小时的第10分钟执行,业务B则在每天的18:10分执行。

看起来好的设计与实现,周末都在为业务排查出了什么问题。不看代码,难以想像一个参数控制了2个业务,还有这么精致的规则在里面。不踩坑都难。如果我们简单的用2个参数分别来控制业务A、B,何坑之有?

小结

我们并不是在一个电脑内存只有128k的时代,我们关心的不是参数能不能复用,我们关心项目的可维护性。感觉每个人写代码的思维方式真的是完全不一样,条条大路通罗马。站在可维护性的角度,坚决抵制一参多业务的编程习惯。

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注