之前因缘既会看到一个单词，bikeshedding，和它背后的故事。想和大家分享一下。wikipedia上可以找到故事原文，我这里简单用现代文描述一下。
上世纪60年代，某国财政部讨论建设核电站的议案，该议案有三个部分。一个是预算10,000,000英镑的核电站，一个是预算350英镑的员工配套自行车棚。一个是每人每年21英镑的午后茶点供应。
在议案的讨论过程中，预算10,000,000英镑的核电站主体部分，经过2分钟的讨论即获通过。因为内容细节太专业了没人看得懂。 而且毕竟人们都认为这个事儿反正要搞嘛。
然后大家对于350英镑的自行车棚的预算金额的合理里展开了激烈了讨论。有人表示车棚用的铝质材料过于奢侈，应该用石锦以节省成本；还有人表示3个月的工期长得不可理喻，说自己在家里后院搭过一下，只用了3天时间。本部分最终以削减50英镑预算而获通过。
最后一个议题也花了一个多小时的时间，但是由于部分细节的缺失，会上没有对此部分展开表决。并要求会后继续补充细节。
这个故事当然是杜撰的，但是道理不爽。在现实中，如果我们细心回想品味，其实也不难找到对应的案例。 在我看来，在软件工程领域，类似自行车棚的东西也很多。比如传输格式用SOAP还是JSON。
与其在这种层面的技术选型上花时间，甚至花时间比较各个方案的代码量、可扩展性、性能，倒不如花时间讨论一下，如何更好地设计框架，以便我们能随时在这些选择上做出变化。
简单而言，对于技术公司，技术层面上对方方面面的斤斤计较也许是必要的。对于非技术型公司，技术层面的选择问题当然也重要，至少不能比同行用的差太多，但是更重要的是技术层面的灵活性，能够快速应对市场变化才是一个业务驱动型公司赖以生存的根本。我相信，所有的产品，都不会听到技术人员如是描述他们系统的现状：
- “数据大多了要分库分表？大概至少两个月吧，涉及的代码太多，而且每个项目访问数据库的方式都不一样，整个过程风险也比较高。”
- “加一个商品品类？这个牵扯甚广啊，需要多个部门协调啊。要不你兼职一下项目经理？”
在非技术公司，还有比技术层面灵活性更重要的事情，就是分析清楚，从业务和系统功能角度，我们到底需要什么。给这些业务功能的重要性分级，并把技术上的问题挂靠在需要这个技术点才能支持的业务功能上。以免空谈技术方案本身的优劣。（这里补充一下，“搞清楚我们到底需要什么”不仅仅是产品的工作，需要产品和技术协同才能达到。这部分内容超过本文范围就不展开了。）
这个话说起来容易，但是具体到实际问题，如果没有点儿功力，可能会面临这样一个严峻的问题：摆在面前的这两个东西，哪个是核电站？哪个是自行车棚？比如：
为了支持大量的业务消息数据，所以要引入Kafka做消息中间件，还要招聘相关的Kafka运维支持人员，为了实现对数据的保密，所以要对Kakfa消息加密，因为我们数据敏感，所以要有审记，要有ACL。 于是要和公司SSO集成。相关配置要能适应业务随时变更的要求，所以以上Kafka的定制行为，要能通过访问公司的配置中心中的配置，完成变更。
请问，上面这段高层需求陈述，从哪句开始陷入了bikeshedding呢？
当然并不是这种选择问题都是bikeshedding，比如用Java还是.NET，服务网关是用Spring Gateway还是nginx这种涉及整个技术栈及人员配置的选择问题还是需要慎重对待的。
但是那个问题又来了，一个公司的技术栈选择和人员配置，到底是一个公司的反应堆的一部分还是反应堆边儿上的自行车棚的一部分呢？