大家好，我是站长 polarisxu。
对开发人员来说，其实也是有不少定律或原则的，只是很多人可能经历了，但不知道原来是这么个定律。
「内卷」这个词很流行，几乎渗透到每一个角落：
想起一个段子：「面试滴滴司机」，对话过程大概是这样的。（来源网络，如有雷同，纯属巧合）
看你简历，你已经有八年的开车经验，咱们聊一聊从你按下汽车点火按钮后，汽车发生的一系列的动作。
答：
1）按下按钮后0.5秒，车辆完成电路自检。 2）按下1秒后，启动机马达的电路被接通，带动马达高速运转，马达转子带动发动机飞轮运动，汽车发动机在轰鸣声中启动。 3）油门踏板控制着发动机进气门（亦称作节气门）的开合角度。油门踩得越深，进气门开合角度就越大，进气量也就越大。 4）然后，火花塞适时点火，引燃可燃气形成“爆燃”，巨大的冲击力使得活塞进行运动。每分钟这样的“爆燃”会发生几百上千次。活塞的运动带动发动机曲轴飞速旋转。发动机转速的，就是每分钟内曲轴旋转的圈数。 5）气缸活塞在封闭爆燃的推动下往复运动，产生连续不断的动力。
至此，发动机顺利完成启动，挂好档位踩油门，转速和车速逐步攀升，我们可以出发啦！
面试官接着问：
嗯，那有在之前的工作中，做过启动优化吗？尽量减少发动的时间，提高用户体验。
。。。
是不是卷的飞起？！
在程序设计中，接口和实现是很重要的两部分。通常在一个系统里面，接口就是一个与系统交互的抽象，比如汽车的方向盘和油门，刹车这些（我们通过这些来控制汽车，与汽车交互），而实现则是这个系统工作的一种方式，比如汽车的轮子和引擎（汽车实际是通过这些来工作的）。区分接口和实现的好处是非常明显的，当一个系统快速迭代，变得越来越复杂和难以理解的时候，抽象能非常好的帮助我们管理这些复杂性。
可见，一个接口在理论上需要清晰的将系统的使用者和该系统的实现隔离开。汽车系统是如此，其他系统也是如此。虽然设计者很努力，但现实往往是残酷的，当这个系统开始逐渐膨胀，一些用户开始依赖一些通过接口暴露出的内部的实现细节，「内卷」开始。。。
几年前，Google 的一名工程师，Hyrum（海勒姆）观察指出：
当 API 有足够多的用户时，你在合同中的承诺已不重要：你系统的所有可观察行为都将被某些人所依赖。
这也叫做「隐式接口定律」。
也就是说，当你的 API 有足够多的用户时，API 的所有行为（包括那些未囊括在公共说明中的一部分）最终都会被其他人所依赖。 一个简单的例子是 API 的响应时间这种非功能性因素；还有一个更微妙的例子是：用户使用正则表达式匹配错误提示来判断 API 的错误类型，即使 API 文档中没有任何关于错误提示的内容，而是指导用户应该使用相应的错误代码。一些用户依然会使用错误提示内容（而非错误代码），这种情况下变更 API 错误提示信息，实际上会破坏 API 的使用。
俗称：不按套路出牌。
随着使用 Go 的人越来越多，大家超越 Go 规范，不满足于 Go 公开的 API，「卷入」其内部实现了。你会写 Go 代码，写过大型项目可能都不够，你必须得符合「海勒姆定律」，挖挖 GMP、GC 等 runtime 很多实现细节。
虽然 Go 官方一直在避免大家陷入实现细节，依赖实现细节，但还是挡不住「爱学习」的人们。比如 Go 中的 map 是无序的，但某个版本的实现，用户测试输出，咦，发现是有序的。。。然后依赖它。Go 官方「一怒之下」，故意打乱顺序。
再比如一个包中多个文件的初始化顺序，规范并没有进行约定。但目前官方的实现是按照文件名顺序初始化的，于是很可能就有面试题，并且多半答案就说是文件名顺序，因为现在是这么实现的，源码在那摆着呢。。。
再比如，Go 中 slice 的扩容，太多太多文章解释，扩容的规则是怎么样的，1.5 倍？2 倍？规范并没有对此做约定。而且 Go 不同版本的实现还经常变。用好 slice 貌似基本不能满足要求，你必须得知道它怎么扩容的，每次扩容增加多少？这跟开车需要知道发动机原理似乎没啥区别~
还有很多很多例子，欢迎留言！
在实际工作中，我们一方面要尽量设计好接口，将接口和实现隔离，但同时也要留意隐式接口问题。特别是对外提供服务（包括公司的基础部门，对其他部门提供服务），要求我们在构建和维护复杂系统的时候思考的更全面一点。我们需要意识到，隐示接口会限制我们系统的设计和发展。虽然隐式接口理论上不是你的锅，但使用者不会这么认为。
所以，「卷」有了理论依据。谷歌很多年前就用理论证明了「卷」的普遍存在，卷的有理有据，你还能不倦吗？🤣
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。