业务开发过程中的特殊逻辑

先说我的观点。如果毫无节制地堆砌特殊逻辑，系统将会逐渐趋向四个字：不可维护。



最近看系统里的业务代码，又看到了一行新的写死的if条件判断。一问，原来是产品新给的要求和原本的功能不通用，只能特殊处理了。



回看整个系统，短短一年的时间，业务代码之间的耦合，逻辑的分支之多，总感觉哪一天可能就崩盘和解体了。



当然，很大一部分原因也是因为代码能力不够硬，设计能力不够软所导致。

可是，充斥过多的特殊逻辑也是不可原谅的一个原因。



特殊逻辑并不是不允许存在，因为技术价值其实是业务落地的价值，如果一味追求代码的完美，而忽视业务的成本，这是更加不可取的。平衡是很重要的。



可是我认为，利器应该花在必要的地方，关键场景才出利器。如果滥用利器，利器也会有变钝的一天。



如果经常都要处理特殊逻辑，系统里就会出现很多的条件判断，这样的堆砌，必然会逐渐增加维护的成本以及大大增加出错的概率。



例如，我原本是配置化的路由列表，现在新增一个路由，你跟我说这个路由比较特殊，出现了之前没有考虑到的变量，需要特殊判断一下。



作为一个程序员，接到这样的需求，那么我更好的做法是什么呢？

1. 先尝试沟通砍掉需求。这样的场景是否真是必须的呢，他会给我们系统和用户带来多大的收益，因为这样做会增加系统的复杂度，之后的维护我们又多了一块牛皮膏药。

2. 如果确实是必须的，那么进一步争取资源去做通用的设计。这个功能是否之后也会出现更多类似的场景？是否可以给多点时间我将这个条件改动到配置里面去，这样的好处是xxx。

3. 如果场景是必须，资源也不足够做通用和规范的设计。那就只能先写特殊处理，要么牺牲个人空闲时间改造，要么事后找产品拿资源。

你看，程序员的生活就是如此的朴实无华，且枯燥。



令我悲哀的是，程序员往往会因为当时的特殊处理的成本比较低，而不加思考就答应产品的要求。



反正就是一两行代码的事，我追求了用户体验的最大化（也有可能是自认为的用户体验最大化），而往往看不到背后的更长期的成本所在。



可是如果我们没有让产品意识到这个事情背后的成本，也算是我们程序员工作的不到位了。



警醒。

克制，真的很重要。