慢慢地走得很快¶
如果我在我的源码树中计算，此时此地，Varnish有100K行的源码：：
75619 lines in .c files
18489 lines in .h files
2625 lines in .py files
670 lines in .vcc files
501 lines in .vcl files
略高于20000行的测试用例：：
21777 lines in .vtc files
略多于20K行的文档：：
22169 lines in .rst files
可能还有大约5K行的“misc”：：
1393 lines in .am files
712 lines in .ac files
613 lines in .lnt files
为了简单起见，让我们称其为整数15万行 [1].
Varnish已经存在10年了，所以每年有15000条生产线。
一年200个工作日相当于一天75条线路。
每天工作7.5小时，每小时就有10条线路。
尽管绝大部分源代码都是我写的，但Varnish远不是一个人的项目。
我无法估计过去十年的平均全职人数，所以让我们选择最糟糕的情况，假设只有两个人是全职的。
由此可以得出结论： no way 根据该项目十年的历史，这两个人的平均产量超过了每小时5行。
这个数字对你来说是低还是高？
不管怎样，程序员整天都在做什么呢？¶
(Yeah, yeah, yeah, I know... )
回到互联网灾难之前，人们实际上已经花费了相当多的时间和精力来找出程序员应该获得什么样的生产力，毕竟，在不知道那个关键数字的情况下，你怎么能估计一个项目？
说得委婉些，结果到处都是，但普遍比大家预期的要低得多。
弗雷德里克·P·布鲁克斯在他的开创性著作《神话中的人月》一书中，将大致的估计为每个程序员每天10行代码投入使用，尽管他在文本中围绕这个数字写的所有内容都主张完全相反。
随着对质量和正确性的终极关注，例如阿波罗和航天飞机软件，生产力下降到每个员工每天不到一行代码。
Varnish生产率的估计上限几乎比布鲁克斯的估计高出一个数量级，与与航天飞机软件相同的质量这一不切实际的目标相比，又是一个很容易被忽略的数值。
所以我们在布鲁克斯球场内，即使有点偏高 [2],
我们怎么花了这么长时间？¶
对5LOC/h数字的惊讶程度无疑与读者的年龄成反比。
当我还是个孩子的时候，我可以在午夜睡眠不足的情况下一次写1000行 [3], 但没过多久，我就发现，一旦我再次醒来，我就得把它吐出来。
我创办瓦尼什的时候40岁，我有22年的专业经验， lot 他们盯着别人的源代码，而且经常修复/改进/重构别人的源代码。
多年来，我开始欣赏安托万·德·圣-埃克苏佩里的观察：
Perfection is attained, not when there is nothing more
to add, but when there is nothing more to remove.
最终，我不再认为代码行是需要积累的资产，而是需要避免的支出。
当我创建Varnish的时候，我个人的主要目标之一是让它成为我有史以来最高质量的程序 [4].
这就是为什么Varnish是用“Pidgin C”风格编写的，而且没有做任何事情的断言很糟糕 [5], 除了澄清程序员的意图 [6], 如果发生错误，在坏事失控之前阻止它们。
这就是为什么在Varnish的源代码中还有其他“毫无意义的开销”，从“mini obj”类型安全上的恐慌/回溯代码到对Gimpl Softwares FlexeLint产品的模糊提示。
不用说，20K行的测试用例使用了超过90%的varnishd源代码行，这也不是偶然的。
坚持把事情做好，而不是 "we can fix it properly later" 这在自由/开源软件源代码中非常普遍。 [7], 也不会增加你的行数。
但它奏效了吗？¶
十年项目周年纪念是一个很好的理由，可以停下来看看是否有预期的玫瑰在那里闻到了。
我们有很多数字，承诺(10538)，错误端口(1864年)，CVE(2) [8] 或者Coverity探测器(一打？)但是，衡量程序质量几乎是不可能的，即使我们往往在看到它时就知道了。
也有数不清的事件应该在分类账中，503s [9], 崩溃、撕裂头发、扭头、喝咖啡、翻阅手册和源代码，以及在IRC上沮丧地呼救。
在另一个杯子里，同样有无形的积极因素，拍拍肩膀，免费啤酒，圣诞节和我亚马逊愿望清单上的生日礼物(谢谢！)，还有更多关于Varnish有多棒的尖刻推文，比我记忆中的要多。
总而言之，我所能做的最好的事情就是说服自己，我没有 totally 射偏了我的目标，是一种《夜色中的狗的奇案》观察：
我从来没有听人说过瓦尼什让他们的生活更悲惨。
我就要这个了。
phk
脚注