背景
Round 1
之前在工作中被吐槽和诟病比较多的一个点，是我们会将很多的特殊业务配置，配置到我们的应用配置中心中；举个典型的例子，我们在业务开票需要发票明细上的税率开始一段时间是单个税率，而到某个时间点，开票明细变为多个税率；在工期比较赶的情况下，为了当机立断解决这个问题，直接留个开关放到配置中心中
引发的问题
1.长时间迭代后，没有人记得这样的一个开关需要开启或关闭 2.当到了时间节点需要开票，历史的单税率还未开完票
复盘
1.隐藏的配置，对用户来说没有暴露出来，很多时候配置的不及时更新就会导致用户操作一些配置联动的按钮造成不便的影响 2.在大家后续的讨论中打算落地一个业务的配置中心用于暴露给用户很多通用化配置 3.可基于编号2我们又会引发一个问题，很多业务配置，真的该做成一个配置吗？或者说他合理吗？
Round 2
而再一次过去一段时间后，最近又一次同样的事件，同样的抉择出现在了我的面前，我们的项目中出现了针对开票出现了两种方式，一种是线上正常走供应商接口开票，一种是走导出线下开票，而这样的功能全部希望集成在一个“确认开票”按钮上，针对一系列的判断，来判断其到底为线上开票还是实际该走线下导出；而初期的评估时看起来没有任何的问题，可中期突然意识到对于TO B的业务而言，很多事情是比较灵活的，在我设计将“确认发票”这个按钮和不同票种绑定触发不同行为时，整个事情就变了，向用户隐藏了逻辑的同时造成了后续的很多不灵活性，比如用户突然遇到某些事就是希望通过线下导出开票，此时一切就都变了；由于我们功能的不够灵活，用户的业务就因为软件的限制而受到阻碍。
再次想向“魔抓”伸向apollo？
此时，身为开发的DNA又动了起来；我开始想的如果遇到操作不够灵活，导致我们需要再一次的发版，这样的成本虽然我们承受的起；但是也许我们的灵活度如果可以更高的话所有人的时间都可以更多的节省掉。留个后手，留个可自定义的配置，或许一切都会变得简单不少？但是此时我还是控制住了自己，不能反复在一件事上重蹈覆辙;也许我这样的做法，短期确实可以使得我们的开发一次性节省了成本，但是我们在基于不修改原型的基础的设计，基于前几次的经验，很有可能会实际上也并不那么好用，同时也隐藏了只有开发知道逻辑和留下了忘记关闭开关，就会造成线上功能不正常的风险……
与产品的二次协商讨论
在基于以上的分析后，我将我的顾虑和产品大佬进行了和盘托出了解相应的解决方案，得到了一个我从来没有想过的方式，将原有的按钮拆解为两个，由用户自己决定各类的发票该导出还是走线上系统，我突然发现有时很多问题，换个角度可能会变得非常不一样；我们站在开发的角度来说，用户的需求和产品的方案就是不变的静止的，我们的浑身解数都是为了能够原原本本的呈现;可实际上，有时简单的调整方案，我们的实现难度和代码的逻辑的清晰度，可能大不相同,而改成两个按钮看似平平无奇，可是，实际上我们的代码层面完全可以实现拆解，并且两类逻辑的触发，从写死的if判断也变成了按钮，可以让用户按照自己的想法去决定实际使用哪一个功能
总结
1.有逻辑的配置最好和产品进行沟通，我们是否真的需要这样的配置？ 2.有时我们的很多思路都是站在自己职业的一个立场上，可是实际上我们换个角度或者站在更高的角度去看一些问题时,可能答案就呼之欲出了 3.文中还有一点是没有分享到的，就是虽然为了这个通用化的设计，引发了很多交流的讨论，收获了新的思路和方案，但是项目进展中途改方案真的是大忌，我为此付出了巨大的代价，真的是为自己狠狠的上了一课
