mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
66 lines
8.4 KiB
Markdown
66 lines
8.4 KiB
Markdown
黑客年暮
|
||
================================================================================
|
||
近来我一直在与某资深开源组织的各成员进行争斗，尽管密切关注我的人们会在读完本文后猜到是哪个组织，但我不会在这里说出这个组织的名字。
|
||
|
||
怎么让某些人进入 21 世纪就这么难呢？真是的...
|
||
|
||
我快56 岁了，也就是大部分年轻人会以为的我将时不时朝他们发出诸如“滚出我的草坪”之类歇斯底里咆哮的年龄。但事实并非如此 —— 我发现，尤其是在技术背景之下，我变得与我的年龄非常不相称。
|
||
|
||
在我这个年龄的大部分人确实变成了爱发牢骚、墨守成规的老顽固。并且，尴尬的是，偶尔我会成为那个打断谈话的人，然后提出在 1995 年（或者在某些特殊情况下，1985 年）时很适合的方法... 但十年后就不是个好方法了。
|
||
|
||
为什么是我？因为我的同龄人里大部分人在孩童时期都没有什么名气。任何想要改变自己的人，就必须成为他们中具有较高思想觉悟的佼佼者。即便如此，在与习惯做斗争的过程中，我也比实际上花费了更多的时间。
|
||
|
||
年轻人犯下无知的错误是可以被原谅的。他们还年轻。年轻意味着缺乏经验，缺乏经验通常会导致片面的判断。我很难原谅那些经历了足够多本该有经验的人，却被<em>长期的固化思维</em>蒙蔽，无法发觉近在咫尺的东西。
|
||
|
||
（补充一下：我真的不是老顽固。那些和我争论政治的，无论保守派还是非保守派都没有注意到这点，我觉得这颇有点嘲讽的意味。）
|
||
|
||
那么，现在我们来讨论下 GNU 更新日志文件这件事。在 1985 年的时候，这是一个不错的主意，甚至可以说是必须的。当时的想法是用单独的更新日志文件来记录相关文件的变更情况。用这种方式来对那些存在版本缺失或者非常原始的版本进行版本控制确实不错。当时我也在场，所以我知道这些。
|
||
|
||
不过即使到了 1995 年，甚至 21 世纪早期，许多版本控制系统仍然没有太大改进。也就是说，这些版本控制系统并非对批量文件的变化进行分组再保存到一条记录上，而是对每个变化的文件分别进行记录并保存到不同的地方。CVS，当时被广泛使用的版本控制系统，仅仅是模拟日志变更 —— 并且在这方面表现得很糟糕，导致大多数人不再依赖这个功能。即便如此，更新日志文件的出现依然是必要的。
|
||
|
||
但随后，版本控制系统 Subversion 于 2003 年发布 beta 版，并于 2004 年发布 1.0 正式版，Subversion 真正实现了更新日志记录功能，得到了人们的广泛认可。它与一年后兴起的分散式版本控制系统（Distributed Version Control System，DVCS）共同引发了主流世界的激烈争论。因为如果你在项目上同时使用了分散式版本控制与更新日志文件记录的功能，它们将会因为争夺相同元数据的控制权而产生不可预料的冲突。
|
||
|
||
另一种方法是对提交的评论日志进行授权。如果你这样做了，不久后你就会开始思忖为什么自己仍然对所有的日志更新条目进行记录。提交的元数据与变化的代码具有更好的相容性，毕竟这就是它当初设计的目的。
|
||
|
||
（现在，试想有这样一个项目，同样本着把项目做得最好的想法，但两拨人却做出了完全不同的选择。因此你必须同时阅读更新日志和评论日志以了解到底发生了什么。最好在矛盾激化前把问题解决....）
|
||
|
||
第三种办法是尝试同时使用两种方法 —— 以另一种格式再次提交评论数据，作为更新日志提交的一部分。这解决了所有你期待的有代表性的问题，并且没有任何缺陷遗留下来；只要其中有拷贝文件损坏，日志文件就会修改，因此这不再是同步时数据匹配的问题，而且导致在其后参与进来的人试图搞清人们是怎么想的时候将会变得非常困惑。
|
||
|
||
或者，如某个<em>我就不说出具体名字的特定项目</em>的高层开发只是通过电子邮件来完成这些，声明提交可以包含多个更新日志，以及提交的元数据与更新日志是无关的。这导致我们直到现在还得不断进行记录。
|
||
|
||
当我读到那条的时候我的眼光停在了那个地方。什么样的傻瓜才会没有意识到这是在自找麻烦 —— 事实上，针对更新日志文件采取的定制措施完全是不必要的，尤其是在分散式版本控制系统中
|
||
有很好的浏览工具来阅读可靠的提交日志的时候。
|
||
|
||
唉，这是比较特殊的笨蛋：变老的并且思维僵化了的黑客。所有的合理化改革他都会极力反对。他所遵循的行事方法在十年前是有效的，但现在只能使得其反了。如果你试图解释不只是git的总摘要，还得正确掌握当前的各种工具才能完全弃用更新日志... 呵呵，准备好迎接无法忍受、无法想象的疯狂对话吧。
|
||
|
||
幸运的是这激怒了我。因为这点还有其他相关的胡言乱语使这个项目变成了很难完成的工作。而且，这类糟糕的事时常发生在年轻的开发者身上，这才是问题所在。相关 G+ 社群的数量已经达到了 4 位数，他们大部分都是孩子，他们也没有紧张起来。显然消息已经传到了外面；这个项目的开发者都是被莫名关注者的老牌黑客，同时还有很多对他们崇拜的人。
|
||
|
||
这件事给我的最大触动就是每当我要和这些老牌黑客较量时，我都会想：有一天我也会这样吗？或者更糟的是，我看到的只是如同镜子一般对我自己的真实写照，而我自己却浑然不觉吗？我的意思是，我的印象来自于他的网站，这个特殊的样本要比我年轻。通过十五年的仔细观察得出的结论。
|
||
|
||
我觉得思路很清晰。当我和那些比我聪明的人打交道时我不会受挫，我只会因为那些不能跟上我的人而
|
||
沮丧，这些人也不能看见事实。但这种自信也许只是邓宁·克鲁格效应的消极影响，至少我明白这点。很少有什么事情会让我感到害怕；而这件事在让我害怕的事情名单上是名列前茅的。
|
||
|
||
另一件让人不安的事是当我逐渐变老的时候，这样的矛盾发生得越来越频繁。不知怎的，我希望我的黑客同行们能以更加优雅的姿态老去，即使身体老去也应该保持一颗年轻的心灵。有些人确实是这样；但可是绝大多数人都不是。真令人悲哀。
|
||
|
||
我不确定我的职业生涯会不会完美收场。假如我最后成功避免了思维僵化（注意我说的是假如），我想我一定知道其中的部分原因，但我不确定这种模式是否可以被复制 —— 为了达成目的也许得在你的头脑中发生一些复杂的化学反应。尽管如此，无论对错，请听听我给年轻黑客以及其他有志青年的建议。
|
||
|
||
你们 —— 对的，也包括你 —— 一定无法在你中年老年的时候保持不错的心灵，除非你能很好的控制这点。你必须不断地去磨练你的内心、在你还年轻的时候完成自己的种种心愿，你必须把这些行为养成一种习惯直到你老去。
|
||
|
||
有种说法是中年人锻炼身体的最佳时机是他进入中年的 30 年前。我以为同样的方法，坚持我以上所说的习惯能让你在 56 岁，甚至 65 岁的时候仍然保持灵活的头脑。挑战你的极限，使不断地挑战自己成为一种习惯。立刻离开安乐窝，由此当你以后真正需要它的时候你可以建立起自己的安乐窝。
|
||
|
||
你必须要清楚的了解这点；还有一个可选择的挑战是你选择一个可以实现的目标并且为了这个目标不断努力。这个月我要学习 Go 语言。不是指游戏，我早就玩儿过了（虽然玩儿的不是太好）。并不是因为工作需要，而是因为我觉得是时候来扩展下我自己了。
|
||
|
||
保持这个习惯。永远不要放弃。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: http://esr.ibiblio.org/?p=6485
|
||
|
||
作者：[Eric Raymond][a]
|
||
译者：[Stevearzh](https://github.com/Stevearzh)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||
|
||
[a]:http://esr.ibiblio.org/?author=2
|