酷应用

真的存在像「怪物」一般的神级程序员么？

百家作者：程序人生 2017-11-20 11:30:28

写在前面的话

从事脑力工作的群体里很容易识别出某些人的工作效率比其他人高出十倍、百倍，比如所谓的“10x程序员”。本文着重列出了“10x程序员”之所以能高效工作的原因。

原文标题丨The mythical 10x programmer

作者丨Redis之父-Salvatore Sanfilippo

翻译丨程序

一般的程序员，能把自己的工作做好就非常不错了。但如果有这样一个程序员，他的工作效率可以抵过 10 个程序员呢？貌似好像很难想象“10X程序员”这样的人会是怎样的一种存在。

所谓的“10x（十倍效率）程序员”，指的就是在编程工作中可以以一当十的神级人物。而一位普通的程序员，即“编程产出量处于平均水平的人”，相较于更专业的编程人员来说，他们可能就会略逊一筹了。

编程界一直对像「怪物」一般的神级程序员是否真的存在，持两极分化的态度：有些人认为，根本不可能存在这种人；而也有一些人认为，世界上不仅存在“10x程序员”，而且如果真的去发掘，甚至能找到“100x程序员”。

如果我们将编程视为一种“线性”学问的话，那么“10x程序员”就是一种看似不合理的存在了。例如，通常情况下，一名赛跑运动员怎么能跑得比其他运动员快十倍呢？又或者是，一名建筑工人，该如何在相同时间内，完成比其他建筑工人多十倍的工作量呢？然而，编程的独特之处，导致我们不能这么简单来看，因为它不是一个“线性”学科，编程靠的是“设计”。尽管程序员们从表面上来看，并没有实施什么切实的设计程序，但实际情况是，他们仍要在潜意识里预先设计好编程策略，然后才能付诸实践或开始编写的过程。

诸如经验、编程能力、知识的积累、辨别“有用”或“无用”的能力，与程序的设计和编写都并非是“线性”的能力，它们都属于“非线性”的优势。将其综合在一起，就能成倍提高编程的效率。当然，如果你能同时掌握好设计和编写的能力，这种倍增的效果也会更好。

除了这些主观因素外，还有一些客观的因素，比如程序员的任务本身是否是“目标导向”。任务越是“目标导向”，那么发掘自己能力的可能性就越大，也就更接近实现10x程序员的境界。但如果任务非常严格，还要求程序员以特定的工具、规定的方法来编程，那么“10x程序员”的技能就很难触发了。

尽管程序员还能在某些地方走捷径来把工作做好，但却无法对编程方法做大幅度的创新。而在这种所谓的大幅度创新中，程序员甚至可能把项目的一部分彻底删掉，从而大大减少了工作量，却也能达成同样的目标。

作为一名程序员我编程已有二十年的时间了。在这二十年中，我观察到许多和我一起共事的程序员们，有时是作为团队的领头人，带领其他程序员来完成一些指定目标——比如为 Redis 或者其他项目提供补丁。与此同时，许多人称赞说我是一位快速编程者。在此我就以自己为例，向大家分享一下快速编程的经验。毕竟我自己不是个工作狂，所以相信我的方法应该也是有参考价值的。

纯编程能力：解决子任务

最明显的一项就是“解决子任务”的能力。要想写好程序，首先你得掌握好每一个基础函数、算法的写法，这就是所谓的“解决子任务”。掌握得好，它会成为突出的优势；掌握的不好，则会成为工作上的绊脚石。

然而惊讶的是，一个对程序员来说是基础的能力，能掌握的人则很有限——据我个人经验来看是这样的。在团队里我常能观察到两类程序员：他们一类能力有限，甚至连简单的分类算法都没听说过；而另一类则是刚从学校毕业的学生，虽然拥有极为完备的理论知识，但真要实践起来去编程，表现却有些糟糕。而一般情况下，单就完成的工作量来看，前者往往比后者更胜一筹。

经验：模式匹配

我所说的经验，指的是那些你已经掌握了的解决方案。

一个经验丰富的程序员掌握了一套既定模式后，你就可以将其应用于大量相似的情境中。并且在不断开发解决方案的过程中，可以不断积累经验，并最终学会如何处理各种子任务。同时，也就能省掉大量耗费在设计上的时间。但更为可贵的是，经验还是一个强有力的武器，它能帮你过滤掉设计中容易产生的错误。错误可谓是编程简洁化的大敌。

集中注意力：实际时间VS假定时间

计算花了多少时间写代码，只看表面的时间是没有任何意义的（因为你只是假定了在那段时间里你都在全神贯注地工作，而实际却并非如此）。我们必须要看所谓的实际有效工作时间才行。

注意力不集中分为主观原因和客观原因。主观原因包括拖延症、对手头的项目不感兴趣、缺乏锻炼、身体欠佳或缺乏睡眠等等。而客观原因可能是会务繁忙、工作环境不佳、同事的频繁打扰等等。

一个看似很自然的能够大幅提高一个人的工作效率的方法，就是集中注意、减少干扰。不过，有些时候为了集中注意力，不得不采取一些极端方法。拿我举例来说，电子邮箱的话，我只会偶尔看一看而非天天查收，甚至其中大部分的邮件我都是不会回复的。

经常会有这种情况发生：某些不重要的任务反倒最繁琐、或者可能会阻碍首要任务的达成（因为首要任务和非首要任务在设计时是存在冲突的）。这种时候，设计的复杂性就涌现出来了。

设计牺牲：牺牲掉5%以达到90%

经常会有这种情况发生，即某些不重要的任务反倒最繁琐、或者可能会阻碍首要任务的达成（因为首要任务和非首要任务在设计时是存在冲突的）。这种时候，设计的复杂性就涌现出来了。

作为一名程序设计师，很重要的一点是必须意识到设计的所有方面并不都是轻而易举的，言外之意，即花的精力和带来的好处是不一定成正比的。一个产出最大化的项目必将是把精力放在那些既重要又可以在合理时间内实现的事情上，所以基于此，你得学会“避轻就重”。

举个例子，当我设计一个叫 Disque 的消息代理时，突然意识到，只要为消息提供尽可能最好的排序，项目的其他方面也能得到大幅提升：包括其可用性、语言查询以及客户端交互、简洁性和各种性能等等。

简洁性

简洁性这一点至关重要。但首先，为了了解简洁性是什么，我们应先看看复杂性是如何产生的。一般复杂性有两个主要成因：一是程序员不愿意进行前面所说的设计牺牲；二是在设计过程中积累了太多的错误。

如果你仔细思考了设计过程的话，你会发现每次出错，都会使我们离最佳解决方案更远一步。一项初步设计错误，如果落到了错误的人手中，即便被发现也不会被更正的。经手者不会重新编写系统，而是会为解决初始错误设计出另一套复杂的解决方案。因而项目在每一步错误中都会朝更复杂、更低效的方向发展。

实现简洁性的方法，即可以将任务拆分成小部分，然后通过推论对其进行“概念验证”。程序员可以在脑海中进行大量简单的设计，然后从中挑选出最直接可行的方案。之后，程序员的经验和设计能力将进一步帮他提升设计成果，从而找出“子设计”任务的解决方案。

但是，每当你需要一项复杂的解决方案时，务必要花足够长的时间去思考如何避免复杂性的产生。只有在找不到更好方法的时候，才可继续发展下去。只要能避免复杂性，即便是大相径庭的方法也务必要考虑。

完美主义会扼杀生产力

完美主义源于两种情况：一种是出于对工程行业的职业习惯，总想在工作中呈现尽可能好的表现；二是个人的性格就是这样。无论哪种情形，完美主义都可能成为程序员快速编程的最大阻碍。碍于完美主义，他们在设计上会产生偏执，做出糟糕的决定。仅仅只是因为心理上的原因、或者无关紧要的可衡量参数然后对设计做极精细的修缮，而这种小修小改对程序的稳健性、简洁性或者及时交付往往没什么帮助。

知识：拥有一些理论会对你有所帮助

当处理复杂任务时，包括数据结构、计算的根本性限制、适合对特定任务建模的算法等等这些知识的储备对你寻找合适设计方案是有重大影响的。不一定要无所不知、无所不晓，但至少遇到一个问题时要能给出多个潜在的解决方法。比如，像前面说的“设计牺牲”（学会接受一定百分比的误差）与基数估计概率算法的知识相结合，就可以帮你避免掉复杂、低速、内存使用率低下的解决方案。

从底层开始：理解机器

在编程时出现的一系列问题，往往都是因为误解了计算机执行特定任务的方式所导致的。因为使用的工具或者算法存在根本问题，甚至会导致需要从头开始对项目进行重新设计和实现。所以，掌握好C语言、理解CPU的工作方式和了解清楚内核如何运作以及系统调用如何实现，则可避免到最后阶段遭遇突如其来的“惊喜”。

调试技能

我们往往会在找bug上花很多的精力。但加入你擅长逐步获取bug的状态，并在合理的步骤内修补好，同时在编写简单代码上不会出太多bug的话，你的编程效率将会有很大的提高。

总之，一位程序员如若具备以上特质的话，那么获得10倍于平均水平的产出就不足为奇了。而且当你善于利用这些特质后，就可从可行模型着手来逐步实现个人设计，这样做出来的东西往往也会比替代方案简单好几倍。

看完此文，你有什么想法或观点呢？欢迎在留言区留言评论。

点击图片get更多精彩