这套程序里有几个动作是发出去之后要等的。让一个网站停下来，等它真的停了才能换文件；让一批文件复制完，等它们都落地了才能继续。
这类「等」的地方一共有 8 处，我全部用了同一套办法，每隔一小会儿去看一眼状态，成了就往下走，一直没成就等到某个时间上限，然后放弃。
两个数字
8 处用的时间上限只有两个。
网站和应用相关的那 4 处，我给的是 30 秒。文件相关的那 4 处，我给的是 30 分钟。
两个数字差了 60 倍。
这不是随手填的。网站启停正常情况下一两秒就好，30 秒是留给异常情况的余量，超过 30 秒基本可以断定是卡住了，再等下去没意义。文件不一样，文件多的时候复制真的要跑很久，半小时都不算离谱。
所以这两档我心里是有数的。我不满意的是另外两件事。
这两个数字还有个问题，它们躺在代码里。8 处里，4 处直接写着「30000」，4 处直接写着「1800000」。没有常量，没有说明。
我当初要是想改其中一档，得记得有 4 个地方要一起改。这种事最容易漏，漏一处之后，同一个动作在不同地方的上限就不一样了，而这种不一致很难查。
这个毛病不严重，但它属于「我明知故犯」的那类。写的时候就知道该提成常量，觉得就 4 个地方，先这样。
等完了，我没看结果
还有一处是真的问题。
等待那套办法里有个关键判断，到底是「在规定时间内等到了」还是「干等到上限也没等到」。程序里明明能拿到这个结果，我把它存在一个变量里，然后从头到尾没用过。
真正决定成败的是另一句，等结束之后，不管是怎么结束的，再去看一眼状态。成了就算成功，没成就算超时。
大多数时候这两句的结果一样，所以四年没出事。但它们的含义不一样。前者是「在时间之内完成了」，后者是「我看的最后一眼它是完成的」。有一种情况会分叉，确实等到了上限，而在超时的那一瞬间状态刚好变成完成，这时候按第二句会报成功。
对网站启停来说，报成功其实无害，它确实起来了。但这件事的后果是，「超时」这个结果不能当作「事情没做成」来用。
我当时大概是先写了前一句，后来改成后一句的方案，忘了把前面那个变量删掉。留着它，看起来像我在用它，其实没有。
我现在的看法
等待的时间上限是个承诺。你写 30 秒，就是在说「我承诺 30 秒内这件事会有结果，没有就是出问题了」。
随手填的数字不是承诺，是个占位符。它不告诉读代码的人任何事，既没说这个动作正常要多久，也没说超过多久算异常。
我写这两档的时候是想过的，想的部分没落到代码里，只有两个孤零零的数字留在那儿。下一个人看到 30000，没法区分这是算过的还是拍的。
这种事补起来很便宜，加一行说明或者提个常量名就够了。难的是当时不觉得需要。
这个工具本身后来开源出来写成了《部署器开源记 · 第 1 篇 · 发版那五步，我为什么没做成命令行》：发版那五步，我为什么没做成命令行。