尺度差异极大的时候, 物理理论都是不兼容的, 应用于宇宙天文尺度应用相对论, 亚原子领域则只能用量子力学. 架构设计, 技术选型需要重视不同项目的维度差异, 不能生搬硬套.

在软件开发领域，工具的延展性超乎想象。以数据库为例，有几张表, 每个表百十行数据的数据库，也不乏上千个表，含有数百万甚至数十亿行数据的库.

编程语言也是, 可以写几行代码的脚本, 也能写数千万行代码的项目.

能适应天文/微观尺度的变化很了不起，但也容易带来一些的错觉, 比如说会觉得所有的项目都差不多.

其实, 软件项目在代码规模, 用户人群, 效率要求上差9个数量级比比皆是.

导致软件人员讨论很多似是而非的问题而不自知, 完全没有注意到蓝鲸(200顿)和蚂蚁(0.2克)的差别, 这会导致很可笑的结果:

• 迷信自己所见, 大多数是baidu上好容易搜索出来的结果, 又或csdn上取到的真经, 完全没有意识到别人的技术决策的场景, 不知道人家的工期, 更也不真正清楚的问题.
• 执着于自己的一些经验, 听不得一点点的其他意见.
• 不当的解决方案，导致过度工程化（不足的情况少见的多）, 什么系统都得拆微服务, 加Redis.

一个软件项目会设计很多的因素（并不按重要性排序）：

• 代码量的大小.
• 开发团队的规模.
• 软件开发团队所在组织的规模.
• 软件团队的人员技术能力.
• 软件开发的组织内部的等级结构.
• 迭代的速度要求.
• 开发的软件的性质, 控制火箭, 心脏起搏器的程序和微信小程序的要求显然是不一样的.
• 软件性能要求, 对于一些软件来说，1%的改进也很重要，而对于其他一些项目，可能比最优解慢上千倍的解决方案也完全可以接受，十倍的优化则完全不值得去搞.
• 软件的用户差别, 用户可能是像你一样的开发者，也有可能是你妈一样的小白用户.
• 开发者与软件用户的关系类型。这可能包括：
  • 开发者就是用户
  • 开发者为用户工作，由他们支付工资
  • 开发者与用户在同一团队工作，一个碗里吃饭
  • 开发者并不直接认识用户，但客户（间接地）支付开发者的工资
  • 开发者不认识用户，用户也不间接支付软件的费用
  • 很多其他变种。
• 软件的用户数量, 这可能会在9个数量级以上变化.
• 软件处理的数据量, 也是一个巨大的范围.
• 软件业务的客单价.
• 你知道你的软件将在哪些硬件上运行的程度.
• 你距离硬件限制有多近（比如嵌入式系统与大多数桌面软件的比较）.
• 你的软件需要在多少种不同的环境（例如，操作系统）中工作.
• 可扩展性要求-从完全不需要到开发人员可扩展或最终用户可扩展（例如使用嵌入式脚本引擎）.
• 长期维护需求, 有些项目可以写完就完，有些项目在发布后几乎不需要变化。而另一些软件将维护几十年.
• 开发人员和维护人员, 在一些项目中，你将拥有一个相当稳定的团队，而另一些项目则全是新人.
• 经济目的也不一样, 有些项目根本没有钱，而对另一些项目来说，钱不是目标。有些人可能会因为“有趣”而吸引新的开发人员.
• 向后兼容需要与外部依赖项, 这里的差异将对需要提前做多少设计产生很大影响.

以上都是软件项目所处的维度。这些维度对技术决策的都会有深远的影响。

考虑到这些因素，变化空间确实是惊人的。两个项目可以在其中10个维度中非常接近，但在其他一些维度中却山水相隔.

可能还有更多我不知道的维度. 事实上, 这个行业里普世真理远没有那么多.

根据个人体验，在大型项目上两三年后的的感受与最初参与时差别很大. 时间和思考, 以及在项目中角色的变化会让我有更完善更深入的视角去切入项目.

技术上什么都知道一点的人, 实际上最没有资格为他人提供具体的技术建议, 碎片化的信息无法有效整合为完整的方案.

技术人员中间, 沉默的永远是大多数, 我们听不到他们的声音, 声音最大的那些人很多时候是贩卖方法论和工具的, 解决其他人的问题不是他们的主要问题, 方法论的销售额才是.

所以我们的耳边充斥着大数据, 分布式, 微服务, K8s诸多名词.... 而实际上, 很多成功的公司的数据库包甚至不到100M的数据.

大多数软件人员同时走向了两个极端：躺在自己的一点点经验上坐井观天，同时又充满了对大厂的莫名崇拜.

正视软件生态的差异, 我们应该有这样的认识：

• 放下执着, 试着从自己的经历中概括和分享, 但是不要强加与人.
• 决不盲从, 倾听其他人的结论，但尽可能多地了解形成这些结论的背景和原因.
• 开放心态, 回归本源, 在自己的维度找到最佳技术方案.