软件工程VS编程
软件工程就是随时间不断集成的编程。
思考：编程是需要考虑时间维度的，软件的生命长度决定了编程时需要考虑的方面，这是因为软件会随时间产生变化。优秀的编程能对任意有价值的变化做出反应，这些变化包括但不限于：
- 依赖
- 业务
- 人员
- 规模
- 数据
- 外部因素（技术/社会等）
有变化就会有风险，如何管理这些风险（或风险预期），是软件工程重要的研究对象。
海勒姆定律
“当⼀个 API 有⾜够的⽤户的时候，在约定中你承诺的什么都⽆所谓，所有在你系统⾥⾯被观察到的⾏为都会被⼀些⽤户直接依赖。” ---- 海勒姆定律
理解：如果你正维护一些被其他工程师使用的项目，需要考虑到他们（其他工程师）不仅会使用承诺的内容（比如API文档中的说明），还可能会依赖其它未显式发布的属性会行为(e.g. hack)
碧昂斯规则
“如果一个产品由于基础设施的变更出现中断或其它问题，但是在我们的持续集成(CI)系统中的自动化测试用例并没有发现这个问题，那么就不应该又负责基础设施的团队承担责任。” ---- 碧昂斯规则
- 规则名字来源
"If you liked it then you shoulda put a ring on it" --- <Single Ladies (Put a Ring On It)> Beyoncé
理解：是应对“海勒姆定律”风险的一种手段，定义“向后兼容”的“后”是什么。这样可以减少基础设施维护者的升级成本（否则，任何升级都会无可避免的变得痛苦不已，且随用户数量而增加）；另一方面在自己的程序中设置过多的隐性依赖也是不负责任的。
左移思想
开发作业流时间线
越早发现问题，成本越低。安全性不能推迟到开发过程结束才检测。
理解： 将问题检测提前可以节省成本。这要求从产品设计，原型设计，测试用例设计，开发设计等阶段都引入检测机制（在我的工作经验中，评审是非常重要的一环）。
权衡与成本
在谷歌内部，人们强烈反感“我说了算”。重要的是，任何议题都要有一个决策者，当决策错误的时候，要有明确的改进路径，但目标是“共识”，而不是“一致”。我们希望看到一些 "我不同意你的衡量标准/评价，但我知道你是如何得出这个结论的 "的情况。所有这一切的内在含义是，每件事都是需要一个理由的。“就是这样，没有理由”、“因为我说了算”或“因为其他人都这样做”是潜在错误的决策。 只要这样做是有效的，当我们面对两个工程选项的总成本而需要做出决策时，应该给出相应的解释。
理解：决策需要考虑的是成本与收益，而不同成本之间有一些是可以总结出相互“转换比较”关系的，如：
- RAM 和 CPU资源 （硬件成本）
- 缓存 和 访问速度 （产品成本）
- 14人天的投入（工程师的时间成本） 和 如果不做这个，这14人天能做点别的（机会成本）
但另一些问题则没有简单的答案：
- 究竟要花多少时间合适？
- 如何度量糟糕设计的工程成本？
- 产品决策的社会影响？
这些问题更多依靠经验、领导才能和先例来协商。
需要意识到，不是所有都是可以量化（衡量、预测）的。
网友评论