TranslateProject/translated/talk/20141108 When hackers grow old.md

黑客年暮
================================================================================
近来我一直在与某资深开源开发团队中的多个成员缠斗，尽管密切关注我的人们会在读完本文后猜到是哪个组织，但我不会在这里说出这个组织的名字。

怎么让某些人进入 21 世纪就这么难呢？真是的...

我快56 岁了，也就是大部分年轻人会以为的我将时不时朝他们发出诸如“滚出我的草坪”之类歇斯底里咆哮的年龄。但事实并非如此 —— 我发现，尤其是在技术背景之下，我变得与我的年龄非常不相称。

在我这个年龄的大部分人确实变成了爱发牢骚、墨守成规的老顽固。并且，尴尬的是，偶尔我会成为那个打断谈话的人，我会指出他们某个在 1995 年（或者在某些特殊情况下，1985 年）时很适合的方法... 几十年后的今天就不再是好方法了。

为什么是我？因为年轻人在我的同龄人中很难有什么说服力。如果有人想让那帮老头改变主意，首先他得是自己同龄人中具有较高思想觉悟的佼佼者。即便如此，在与习惯做斗争的过程中，我也比看起来花费了更多的时间。

年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验，缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人，却被<em>长期的固化思维</em>蒙蔽，无法发觉近在咫尺的东西。

（补充一下：我真的不是保守党拥护者。那些和我争论政治的，无论保守党还是非保守党都没有注意到这点，我觉得这颇有点嘲讽的意味。）

那么，现在我们来讨论下 GNU 更新日志文件（ChangeLog）这件事。在 1985 年的时候，这是一个不错的主意，甚至可以说是必须的。当时的想法是用单独的更新日志条目来记录多个相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也在场，所以我知道这些。

不过即使到了 1995 年，甚至 21 世纪早期，许多版本控制系统仍然没有太大改进。也就是说，这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上，而是对每个变化的文件分别进行记录并保存到不同的地方。CVS，当时被广泛使用的版本控制系统，仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕，导致大多数人不再依赖这个功能。即便如此，更新日志文件的出现依然是必要的。

但随后，版本控制系统 Subversion 于 2003 年发布 beta 版，并于 2004 年发布 1.0 正式版，Subversion 真正实现了更新日志记录功能，得到了人们的广泛认可。它与一年后兴起的分布式版本控制系统（Distributed Version Control System，DVCS）共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分散式版本控制与更新日志文件记录的功能，它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。

有几种不同的方法可以折衷解决这个问题。一种是继续将更新日志作为代码变更的授权记录。这样一来，你基本上只能得到简陋的、形式上的提交评论数据。

另一种方法是对提交的评论日志进行授权。如果你这样做了，不久后你就会开始思忖为什么自己仍然对所有的日志更新条目进行记录。提交元数据与变化的代码具有更好的相容性，毕竟这才是当初设计它的目的。

（现在，试想有这样一个项目，同样本着把项目做得最好的想法，但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决....）

第三种办法是尝试同时使用以上两种方法 —— 在更新日志条目中，以稍微变化后的的格式复制一份评论数据，将其作为评论提交的一部分。这会导致各种你意想不到的问题，最具代表性的就是它不符合“真理的单点性（single point of truth）”原理；只要其中有拷贝文件损坏，或者日志文件条目被修改，这就不再是同步时数据匹配的问题，它将导致在其后参与进来的人试图搞清人们是怎么想的时候变得非常困惑。

或者，正如这个<em>我就不说出具体名字的特定项目</em>所做的，它的高层开发人员在电子邮件中最近声明说，提交可以包含多个更新日志条目，并且提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。

当时我读到邮件的时候都要吐了。什么样的傻瓜才会意识不到这是自找麻烦 —— 事实上，在DVCS中针对可靠的提交日志有很好的浏览工具，围绕更新日志文件的整个定制措施只会成为负担和拖累。

唉，这是比较特殊的笨蛋：变老的并且思维僵化了的黑客。所有的合理化改革他都会极力反对。他所遵循的行事方法在几十年前是有效的，但现在只能适得其反。如果你试图向他解释这些不仅仅和git的摘要信息有关，同时还为了正确适应当前的工具集，以便实现更新日志的去条目化... 呵呵，那你就准备好迎接无法忍受、无法想象的疯狂对话吧。

的确，它成功激怒了我。这样那样的胡言乱语使这个项目变成了很难完成的工作。而且，同样的糟糕还体现在他们吸引年轻开发者的过程中，我认为这是真正的问题。相关 Google+ 社区的人员数量已经达到了 4 位数，他们大部分都是孩子，还没有成长起来。显然外界已经接受了这样的信息：这个项目的开发者都是部落中地位根深蒂固的崇高首领，最好的崇拜方式就是远远的景仰着他们。

这件事给我的最大触动就是每当我要和这些部落首领较量时，我都会想：有一天我也会这样吗？或者更糟的是，我看到的只是如同镜子一般对我自己的真实写照，而我自己却浑然不觉？我的意思是，我所得到的印象来自于他的网站，这个特殊的笨蛋要比我年轻。年轻至少15岁呢。

我总是认为自己的思路很清晰。当我和那些比我聪明的人打交道时我不会受挫，我只会因为那些思路跟不上我、看不清事实的人而沮丧。但这种自信也许只是邓宁·克鲁格效应（Dunning-Krueger effect）在我身上的消极影响，我并不确定这意味着什么。很少有什么事情会让我感到害怕；而这件事在让我害怕的事情名单上是名列前茅的。

另一件让人不安的事是当我逐渐变老的时候，这样的矛盾发生得越来越频繁。不知怎的，我希望我的黑客同行们能以更加优雅的姿态老去，即使身体老去也应该保持一颗年轻的心灵。有些人确实是这样；但可惜绝大多数人都不是。真令人悲哀。

我不确定我的职业生涯会不会完美收场。假如我最后成功避免了思维僵化（注意我说的是假如），我想我一定知道其中的部分原因，但我不确定这种模式是否可以被复制 —— 为了达成目的也许得在你的头脑中发生一些复杂的化学反应。尽管如此，无论对错，请听听我给年轻黑客以及其他有志青年的建议。

你们 —— 对的，也包括你 —— 一定无法在你中年老年的时候保持不错的心灵，除非你能很好的控制这点。你必须不断地去磨练你的内心、在你还年轻的时候完成自己的种种心愿，你必须把这些行为养成一种习惯直到你老去。

有种说法是中年人锻炼身体的最佳时机是30 岁以前。我以为同样的方法，坚持我以上所说的习惯能让你在 56 岁，甚至 65 岁的时候仍然保持灵活的头脑。挑战你的极限，使不断地挑战自己成为一种习惯。立刻离开安乐窝，由此当你以后真正需要它的时候你可以建立起自己的安乐窝。

你必须要清楚的了解这点；还有一个可选择的挑战是你选择一个可以实现的目标并且为了这个目标不断努力。这个月我要学习 Go 语言。不是指游戏，我早就玩儿过了（虽然玩儿的不是太好）。并不是因为工作需要，而是因为我觉得是时候来扩展下我自己了。

保持这个习惯。永远不要放弃。

--------------------------------------------------------------------------------

via: http://esr.ibiblio.org/?p=6485

作者：[Eric Raymond][a]
译者：[Stevearzh](https://github.com/Stevearzh)
校对：[Mr小眼儿](https://github.com/tinyeyeser)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出

[a]:http://esr.ibiblio.org/?author=2