今天，我写了一段扩展性很差的代码。但是这不是我自愿的，也没有“人”强行逼我，只是“形势”所迫，而不得不这么做。今天的代码，可能会成为明天的坑，而明天后来人补坑的时候，希望多看看Annotate，多想想代码是如何写成这样的。所以希望，不要因为我写的这段代码而骂我。

明天的坑

开发的先行中的人

开发其实是一个漫长的过程，但是在最初开发的人，往往可以奠定这一模块的整个基调。就好比盖房子打地基，最先打好地基的人，可以享受这个地基的特性所带来的便利。但是这种往往会给后人带来很多的不便，今天我就用一个例子来说一下我是如何写这段扩展性很差的代码的。

需求

首先我先简单说一下需求，就是根据服务端下发的优惠券信息List，前端展示不同的优惠券选择样式，可以看一下流程图：

原逻辑

希望大家都能看得懂，画的不是特别好。然后现在又加了一个需求，服务端下发的优惠券List中有可能不可以展示，但是可以使用，就需要改成以下的逻辑：

现逻辑

然而，这么改的话，其实会增加很多后期维护的成本，根本不易于接下来的开发。比如新增一个需求，新增一个优惠券样式D，要求包含某种优惠券的时候就展示这个样式，原逻辑就需要在两个if else分支都添加这种样式的展示方法。而接下来的逻辑其实只需要在一个地方添加就可以了。
接下来是我个人认为的比较好的逻辑，这种方式可以将分支减少，只有一个主要判断的分支：

个人认为比较好的逻辑

为什么这种方法会比之前的好呢？if else逻辑什么样才是好的逻辑？

我认为绝大多数if else都可以转成switch。switch语句看起来比if else简单多了，也清晰多了，所以我认为只要可以将if else转换成switch的都是一个不错的逻辑设计，而多层的if else只会让人看得头疼，所以在开发中尽量避免使用多层嵌套的if else，可以大大降低维护成本。

我遇到最厌烦的事

其实，扩展性很差是一个很常见的问题。在维护中，相比于扩展性差的代码，我对于无缘无故的复杂而又不适用又不易扩展的架构更厌烦，真想问问那些所谓的“架构”，你们真的有考虑过今后的功能才这么设计架构的吗？还是仅仅为了业绩，为了自己的体验。

最后，最简单的事

说实话，我认为最好的不是说你设计了多么完美的架构，兼容了多长时间的开发，而是在你所开发的过程中，尽量的用最简单的代码，完成最复杂的逻辑。这样，无论是以后后人进行修改Bug的时候，还是进行兼容性整合的时候，都可以剩下双方很多的是时间。毕竟时间就是金钱，我的朋友。

作者：AllAboutCoding
链接：https://www.jianshu.com/p/58fc4845595b