今天下午被一个“技术”问题缠着，想了很久，都觉得无法涵盖所有异常情况，还存在着「先有鸡还是先有蛋」的问题。

简单来说，为了让用户操作起来比较顺畅，在前端点击一个按钮的时候，会触发后台两个动作，先后调用两个接口，但对用户来说，感受不到分了两步，一切都在一次点击之后发生。

但既然实际上是两个步骤，就必然存在先后顺序，因此也就存在当中一个步骤发生异常时，应当采取什么样的方式让用户可以继续进行下去。

而症结在于第二个步骤需要依赖第一个步骤成功之后获取的一个编号才能继续，第二个步骤可以理解成在这个编号上追加一些新数据。那么，问题就来了，如果第二个步骤失败了，在一个按钮的情况下，如何让用户仅仅去重新执行第二个步骤？

当时我所有的思绪都集中在分析各种可能出现的异常，以及针对这个异常前台如何去处理，比如，需要记录一些状态，以便当第二个步骤失败时，可以做到仅仅提交第二个步骤。

深陷其中的我，得出了一套还算全面的判断逻辑，但总觉得哪里别扭着，而且对于前端来说过于复杂（回头想想，简直就是在用做后端的逻辑去写前端！）

无法自拔的我，决定好去征询大牛的意见，大牛一张口，真的是「一语点醒梦中人」，甚至于让我为问出这个问题而感到羞愧🤦🏿‍♀️，脑中漂浮着无数个「天呐」，我怎么没有想到！为什么我会在这个问题上犯傻了这么久！

大牛的答案是，后端把这两个步骤合并成一个，所有的逻辑在这一个接口里实现。

我恍然大悟，为什么完全没有从这个角度考虑过，一味地在想如何让前端将两次调用假装成一次操作，可最简单的难道不是就真的就变成一次操作吗？

回家的路上，我反复在思考这个问题「为什么我没想到？」，这个问题本身其实并没有上升到疑难杂症的技术难题的程度，尤其事后回想起来，多么明显的一个答案居然被我忽略了。

直到现在回顾这个过程并写下这些文字，我才找到了一点点缘由。大概是因为：

我缺乏推倒重来的勇气

我所做出的选择都是在不断地去贴合现在的设计和代码逻辑，而不是直接推倒重来，写一个合二为一的新接口就好了啊！我之所以不满意之前自己所做出的方案，因为那充其量只是在现有状态下的修修补补，不能彻底解决问题。

思路也被限制了，面前有一瓶水和一个杯子，把水倒到杯子里喝，但却忘记了可以直接拿起瓶装水来喝。事后的回顾总是那么清晰有条理，甚至于很是想不通自己当时为什么会陷入这种思维的怪圈怎么也跳不出来。

在那个当下，尽管我在很认真地分析问题，但大概内心深处还是希望能通过「最小的变动」去解决这个问题，有了这样一个限制，很多路其实就被堵死了，也失去了很多可能性。

为什么技术型的人去做产品会有一定的限制，其中一个原因就在于 Ta 太清楚边界在哪里了，哪些可实现，但这些「可实现」的前提是 Ta 自己的技术天花板，而没有「技术包袱」的人就不一样了，不怕做不到，就怕想不到。你说，这样两类人能不打起来了吗…

技术和天马行空，怎么样才能和谐共生呢，大概是一个亘古的问题。