简单是唯一标准吗？

很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。简单没有错，问题是简单就是指这一次改动的简单呢？那运维的简单性、扩展的简单性、稳定的简单性、排查的简单性呢？

现象

很多时候讨论方案，“这个改起来简单”，然后就没有人说话了。

因为这东西真有点无从反驳。

改起来简单，风险就低，你怎么反驳，又不是你改，又不是你背锅。

包括网络上有一些图，基本表达是"能跑就别动"。

但是这玩意真的对吗？

有些时候不是跑的问题，是业务发展、竞品拼杀、商业博弈，必须有做一些特性和功能，这个时候是必须要动。

动不是问题，问题是怎么动，衡量标准是什么。

简单没有错，问题是简单就是指这一次改动的简单呢？

那运维的简单性呢？扩展的简单性呢？稳定的简单性呢？排查的简单性呢？这些都不谈？

比如要对接第三方备份厂商，居然有其他厂商入侵到我们计算节点，并且到我们计算节点删除 img 的操作方案。

可能这次是简单了，那下次呢？下个备份厂商呢？

包括备份对接 s3 接口，多好的需求，符合生态，非常标准化。

结果硬是做成了非标能力，绑定存储，绑定各种特定流程，非得模仿老功能，依赖中转节点。

难道就不能从计算节点直接上传 s3？

数不胜数的例子，这类问题，基本都是当时评审的时候"这个方案改动小"导致的。

这类问题其实真无解，就看 leader 的品味。

因为其他队员发言是没有权威的，文无第一。

尤其是"改动小"，比如你的方案实现了从计算节点直接上传备份到 s3，并且是标准 s3 接口，以后不做改动对接任何备份厂商。

很好吧，所有人都知道这是对的，但是不会有人主动去赞同，因为改动大，得背锅。

这类问题短期没有人在意，但是时间长了，赚钱的部门、商业线第一个跳出来：

“你们写的代码怎么这么多限制，为什么别人支持，我们不支持，很奇怪。为什么这个支持 s3，那个不支持，很奇怪。”

不过到这依然没有结论，依然看 leader 的品味，看老板的品味。