通过设置内部 registry，我们可以更进一步，在导入开源库之前就对有污染性的开源协议进行评估，如何更好的利用开源产品。
接下去，就是“ never-build-twice ”这个功能的开发，充分利用之前已有的 build 成果。

然后你还可以进一步考虑，怎么进一步接管整个灰盒测试流程啊这种，比方说，只能在线上验证的代码，怎么自动划分一部分给 pre-Prod staging/baking，怎么做 One-Box baking，怎么 lock 住 stage 防止在高峰流量的时候部署？怎么管理运行时环境的环境变量？怎么用这个做服务端 shadowing(保证除了特定流量之外行为和原来完全一致)

反正这一整套 feature 下来，估计你也升职了，我一个 SDE1 就不多嘴了

我建议这样子，用 k8s/docker 接管所有生产环境的构建流程，然后库之类的外部依赖统一走公司内部的 registry，不允许 override。
build 过程中只能访问内部 registry 就可以避免用一些 hacky 的方式拿外部包、库的问题了。
然后强制所有的库依赖都必须在 dependency.xml 或者 package.json 里面写明白。

这样就直接避免了大部分问题。

如果你们已经有内部的 CI/CD 的话，要做的就是 1.写几个包管理器的 wrapper 2.写几个包管理器的配置文件的解析，然后和你们内部的 email 系统 /工单匹配，pre-build 扫描，定期全局扫描，发现问题就发邮件。

^1. hijack 也好，包管理器 registry 设置也行，其实难度不高的。

录音+调解啊？这都要人教？

感觉还是 withings 好 续航长真的太重要了，其实就需要闹钟 心率 提醒这几个功能罢了

亚马逊有一整个 builder tools team 维护了一个内部的版本管理系统 依赖写在 config 文件里面，有个组会扫描依赖文件然后自动化发邮件的

Avg?lz 原来做哪部分的？代码？

@Osk 大佬啥叫菜羊 SoC，可以讲讲吗？

高度设定成 node.height = max{node.left.height, node.right.height} + 1, splay(x)的时候顺手维护，在取的时候就找一条路满足 node.height = node.[left/right]+1 就可以一路找到最长路了

第二个在 splay 的时候做一下不就完了？把最常用的扭上来之后更新被扭的那个节点的高度就成了

建议找个大公司的职位学学正确的设计方法，感觉偏野路子了

日系微整容比韩式一刀切强很多，也贵太多

@lusheldon 年轻气盛就是这样的。相关性到现在依旧符合。是不是 2015 年发生了什么导致之后的人都怒气值爆表的？

一时好奇，翻了下楼上所有人的注册时间。奇妙的相关性：2015 年前注册 V2EX 的起码都还在等代码出来，2015 之后的一个个都开始对着空气靶子输出了

TypeScript 已经是标配了，各种地方都有 TypeScript，事实证明，强类型+强制标注，确实是有利于开发的

哪儿实用了

glibc 依赖不对可以让这个包跪在地上哭（我就这么被一个中老年版本的 linux 系统整哭过，就差没跪在地上求管理员爸爸升级系统了

Typora 对我来说是很好的工具，唯一缺点是：咋还不收费啊，你倒是收费啊，你不收费我特担心哪天就不维护了。