大家好，我是站长polarisxu。对于开发者来说，其实有很多规律或者原则，但是很多人可能都经历过，只是不知道就是这么一个规律。“内卷”这个词很流行，几乎渗透到每一个角落：幼儿园的孩子学了一年级的知识，但如果你家不学，一年级就跟不上了。..小学生上各种课外补习班。不报班，没人陪，就让他看电子产品？采访造火箭、工作拧螺丝的现象更为严重。..公众号各种卷：书名、内容等，卷王中的王出现了。.....想起一个笑话：《采访滴滴司机》，对话过程大概是这样的。（来源网络，如有雷同，纯属巧合）看简历，八年驾龄。让我们谈谈按下点火按钮后车内发生的一系列动作。答：1）按下按钮后0.5秒，车辆完成电路自检。2）长按1秒后，启动电机电路接通，带动电机高速运转，电机转子带动发动机飞轮转动，汽车发动机发出轰鸣声启动。3）油门踏板控制发动机进气门（又称节气门）的开闭角度。油门踩得越深，进气门的开闭角度就越大，进气量就越大。4）接着，火花塞适时点火，点燃可燃气体形成“爆燃”，巨大的冲击力使活塞运动。这种“爆燃”每分钟发生数百次或数千次。活塞的运动带动发动机曲轴快速旋转。发动机转速是曲轴每分钟的转数。5)气缸活塞在封闭爆燃的推动下作往复运动，产生源源不断的动力。至此，发动机已经成功启动，挂上档位，踩下油门，车速和速度会逐渐加快，我们可以起步了！面试官接着问：嗯，你在之前的工作中有没有做过启动优化？最小化启动时间以改善用户体验。...音量在飞？！01Hiram'sLaw在编程中，接口和实现是非常重要的两个部分。通常在一个系统中，接口是与系统交互的抽象，比如汽车的方向盘、油门、刹车（我们用这些来控制汽车，与汽车交互），实现是一种方式使用系统的工作，例如汽车的车轮和发动机（这是汽车实际工作的过程）。区分接口和实现的好处是非常明显的。当一个系统快速迭代，变得越来越复杂和难以理解时，抽象可以帮助我们很好地管理这些复杂性。可见，一个接口在理论上需要将系统的使用者与系统的实现明确隔离开来。汽车系统如此，其他系统也是如此。尽管设计师们很努力，但现实往往是残酷的。当系统逐渐扩展时，一些用户开始依赖通过接口暴露的一些内部实现细节，“内卷”开始了。..几年前，谷歌的一位工程师海勒姆（Hyrum）观察到：当API拥有足够多的用户时，你在合约中的承诺并不重要：你系统的所有可观察行为都会被一些人所依赖。这也称为“隐式接口法则”。也就是说，当你的API拥有足够多的用户时，API的所有行为（包括那些没有被公开描述的部分）最终都会被其他人所依赖。一个简单的例子是API的响应时间等非功能性因素；还有一个更微妙的例子：用户使用正则表达式匹配错误信息来判断API中的错误类型，即使API文档内容中没有关于错误信息的任何内容，但指示用户适当的应该使用错误代码。有些用户仍然使用错误消息（而不是错误代码），在这种情况下，更改API错误消息实际上会中断API的使用。俗称：不按套路出牌。02这一规律在Go中的体现随着越来越多的人使用Go，大家超越了Go规范，不满足于Go的公共API，“介入”其内部实现。会写Go代码，写大型项目可能还不够。你必须符合“Hyram'sLaw”，挖掘出GMP、GC等很多runtime的实现细节。虽然Go官方一直在避免大家纠结于实现细节而依赖于实现细节，但依然挡不住“爱学习”的人们。比如Go中的map是无序的，但是某个版本的实现，用户测试输出，哎，发现是有序的。..然后依赖它。去官场“一气之下”故意乱序。再比如一个包中多个文件的初始化顺序，规范中并没有规定。但是目前官方实现的是按照文件名顺序初始化的，所以可能会有面试题，大部分的回答都是说文件名顺序的，因为现在是这样实现的，源码是有的。..再比如，Go中切片扩容的文章太多了，扩容的规则是什么，1.5倍？2次？规范对此没有规定。此外，不同版本的Go的实现经常变化。好好利用slice貌似基本达不到要求。你一定知道它是怎么膨胀的，每次膨胀多少？这好像和开车时知道发动机原理没什么两样。还有很多很多例子，欢迎留言！03对我们意味着什么？启示在实际工作中，一方面要尽量做好接口设计，将接口与实现隔离，但同时也要注意隐式接口的问题。尤其是对外提供服务（包括公司的基础部门和为其他部门提供服务），需要我们在构建和维护复杂系统时考虑得更全面。我们需要意识到隐式接口限制了我们系统的设计和开发。虽然隐式接口理论上不是你的错，但用户并不这么认为。因此，“量”是有理论依据的。谷歌在很多年前就用理论证明了“体积”的普遍存在。该卷是合理且有充分根据的。还能不知疲倦吗？？？04参考Hyrum法则：https://www.hyrumslaw.com/本文转载自微信公众号「polarisxu」，可通过以下二维码关注。转载本文请联系polarisxu公众号。
