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

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

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

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

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

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

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

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

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

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

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

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

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

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

警醒。

克制，真的很重要。