Post #110

但是对公司而言，让自己跑得更快远比让竞争对手跑得慢一点更重要。所以大部分情况下保密措施应该是以不伤害效率为前提的。对用户数据的保密除外，但是保护用户数据的措施通常不会影响到大部分人的工作效率。 理论上这些都可以被滥用或者误用，但是滥用往往缺乏动机，误用可以从设计上避免。一个大原则是风险可控或可逆的事情默认是没有流程的，只有实际发生了问题，证明必要时才会靠引入流程来解决。有了流程就需要有人审批有人执行，如果它解决的问题不常发生、有其他方案或者产生的危害不如流程带来的成本，那么设立流程就是不理性的。 有的比较卷的团队为了控制代码的复杂度，还把自己 code base 的行数上限放到了测试里。如果有人增加了 10 行代码，就需要重构其他地方的代码来省出 10 行，或者提供一个好的理由来提高上限。 除了日常的 code review 外，每个新员工会需要学习公司的代码规范，并通过工作中会用到的每个语言的可读性 review。方式是准备一个百行以上的 changelist，提交给一个有资格做 readability review 的工程师，通过之后才有权限提交用在生产环境的代码。 所以 Google 把版本管理完全倒了过来，每个项目/组件都只要维护一个最新版，所有的改动最重要的原则是不能破坏任何测试。所以如果有人在一个共享组件里做了向前不兼容的改动，就会需要在同一个 changelist 里把整个代码库里所有调用到这个接口的地方改过来。 GWS 每周会做一次 binary push，也就是二进制文件的发布。流程是每周一早上负责发布的工程师从当前的代码做一个发布分支编译出一个二进制文件，交给 QA 开始测试，发现 bug 就把修复 cherry pick 到发布分支。 https://1byte.io/google-large-scale-dev/