这么设计参数，新人不掉坑里才怪
source link: http://www.jishudao.com/2020/05/31/design-params/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
最近遇到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的时代，我们关心的不是参数能不能复用，我们关心项目的可维护性。感觉每个人写代码的思维方式真的是完全不一样，条条大路通罗马。站在可维护性的角度，坚决抵制一参多业务的编程习惯。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK