最近遇到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的时代，我们关心的不是参数能不能复用，我们关心项目的可维护性。感觉每个人写代码的思维方式真的是完全不一样，条条大路通罗马。站在可维护性的角度，坚决抵制一参多业务的编程习惯。