将近一年时间过去了。

从我开始陷入这个梦魇，到我终于打败它。将近一年时间过去了。

即便我以为自己已经忘记。

当测试跑起来我的心率就陡增的那一刻。

当我熟练的敲下重复运行二十遍的命令的那一刻。

我知道它从没有退去。

---

作为一个测试用例，dslabs的lab 3，test 18是非常糟糕的。

原因只有一个，过于模糊。

在解决了所有 真正的 liveness问题以后，才是真正痛苦的开端。太痛苦了。

测试结果是模糊的。

一个与我最终版本的程序相差无几的次优版本，最大等待时间经常在1000毫秒上下，很多时候达到800毫秒，但少数时候会达到1600甚至1800毫秒。

这算是测试通过吗？

更不用提一个过于鬼故事的现象，按顺序跑所有测试用例的时候最大等待时间常常比单跑要长一点。

测试目标也是模糊的。

我应该把程序优化到一个什么程度，才算是 符合 了这个测试的预期？

如今我依然深刻的记得去年对于这个问题的纠结。

如今我终于可以自认为 彻底 解决了这个测试。因为我可以确信自己写出了某种意义上最优的实现。

这个最优是理论层面的。它发送的消息数目最少。它的状态最简单。而测试的指标，最大等待时间，只是这些内部参数的一个外部体现。

一方面我找到的最优，这意味着不管这个测试想要我做到什么程度，我都已经做到了；另一方面最大等待时间再也很难超过1000甚至800毫秒，并且有时可以低到400多毫秒，这个分布总算可以让我安稳入睡了。

但这对于一个初学者来说太奢求了。

我很清楚自己写下的每一行代码所需要花费的 时间 。我需要花多少时间去深入的理解多少模型，去积累多少经验，才能意识到这一行代码应该这样写，才能把这一行代码写对。

我很清楚自己花了多少时间和努力，才能够准确的理解log当中一条条平平无奇的收发消息，背后蕴含着怎样的设计隐患。如果有学生把ta的log贴出来，我也许可以告诉他我从中看出了什么，但很难指望这种沟通的效率。

哪怕我觉得自己已经在完成这个测试的路上健步如飞了，我还是在2022年的现在改了一轮又一轮，前后好几天。想错了不少次。Paxos真是麻烦极了。

如今我相信自己可以给学生提供一些可以量化的指标，来帮助他们设计和优化实现了。

比如一次选举应该在多少毫秒内完成。比如选举应该是几乎一定成功。比如该触发多少次选举。比如选举最多产生多少重新提案。

只有当我真的写了一个实现，它可以次次都不超过700多毫秒，我才有底气给学生讲，你这个实现还能做的更好，如果平时就老是超过1000毫秒，那么担心出现黑天鹅事件而挂掉测试本来就是应该的。

就像去年的我一样。根本不能理解自己写出来的代码。不能理解它快的时候为什么快，慢的时候为什么慢。

那时候没有人熟悉这个测试，所以只能自己探索。现在好歹我可以顶着一盏探照灯在前面开路了。

但是归根结底，我还是在企图要求他们在这个测试上面有更深刻的理解。比我去年写完了以后还深刻的理解。因为我希望他们写的比我去年写的好。他们可以通过现在的我比去年的我得到更多的信息。但是说到底我还是在要求他们做的比我好。

不知道这到底会不会是不现实的。