Ⅰ效率的前提是高可用

如果程序根本无法正常运转，对其效率、适应性及生产成本的评估就毫无意义。
摘自 优秀程序的要素 ——《程序开发心理学》

我觉得这个非常重要，如果不能保证自己写的代码是高可用的，一上线一堆 bug，那就毫无意义，因为在总工时上还是大量损耗的。

但，这就涉及另一个问题：如果写出来的东西因为延期，最终无法上线；或者在前期花费了大量时间之后，开发出来的功能仍然 bug 频出，那这额外花费的时间就无法解释了。

这似乎有点悖论，因为我们无法保证写出来的东西没有 bug。

但或许我们可以想想，怎么尽量减少 bug，保证质量。

一、怎么保证高可用？

我们或许可以通过单元测试来保证，但单测写起来真的很痛苦。

既然单测切实有效，那就来解决一下这个问题，而不是逃避。

这一小节是对单元测试的方法的讨论，之后我们再来聊单元测试有多重要

面向测试的编程，面向行为的测试。

这是从之前在 极客时间 上学到的方法。

从一开始做准备未打开编辑器之前，就先把测试、上线的环境部署好，如果用 Jenkins 等各种 CI/CD 就更好了，现在搭建好，到时候就只是一次普通的 提交&构建 。

如果一开始只是在开发，开发完成后，确实显得开发时间很短，但这些部署的时间反而会凸显出来，让大家感觉：为什么上个线这么麻烦？

程序开发中经常遇到的一个问题是要符合开发的日程计划，推迟完成的程序常常没有意义。
最起码地说，我们不得不比较一下，到底是一个可能（在未来）完成的高效率程序带来的潜在节省更大，还是没有一个程序的损失更大。
写到这里，我去拿出了多抓鱼买的二手《程序开发心理学》

也就是说，我们要考虑实际和计划间的偏差幅度。