21CTO导读

光驱有4x,8x,16x，36x,（这里的x读速），即读写光盘的速度，程序员干活效率也有快慢高低。在经典软件工程书《人月神话》的作者FrederickP.Brooks.Jr.这样说道，『好的程序员和差的可以达到100倍的效率差别，我还没搞清怎么做到的，但是现实中，好的程序员与差的程序员完全可以达到1：5到1：10的效率比。』

Antirez（Salvatore Sanfilippo，Redis之父）最近在个人博客中提到：如果把编程工作看作是一门“非线性”学科的话，那么不仅有10x的程序员，甚至连100x程序员这样的怪咖异类都有，他还举出了他自己认为的10x程序员必备的一系列素质。

以下为正文。

『10x程序员』，指的是在编程工作中，他的开发效率是『普通程序员』的10倍。

所谓的普通程序员指的是擅长所做的工作，但却没有10x程序员那种能量的程序员。这样说可能更好，『普通程序员』是指在研发团队中的保持平均产出的人。

对于这样一种异类是否存在，在开发者社区有着这样两级分化的观点：有人说所谓的10x程序员并不存在，而有人则说10x程序员不仅存在，而且甚至100x程序员都有，如果你知道去哪儿找的话。

如果把编程看作是『线性』的学科，显然『10x程序员』的存在不合逻辑。一哈皮跑步运动员怎么可能比另一个人快上10倍？亦或一名建筑工人在相同单位时间内建造的东西怎么可能比另一个多10倍？事实上，编程是一门设计学科，属于一种特殊的设计。即便程序员并未参与到实际的架构设计当中，但实现本身仍然需要对实现策略进行子设计。

在我看来，如果程序设计和实现不是一种线性能力的话，像经验、编码能力、知识、对无用部分的识别等这些就不仅仅是线性优势，汇聚到一起会对编程产生倍增级效应。

当然，如果程序员能够同时处理程序的设计和实现时，这种现象会出现很多。任务越是“目标导向”，『10x程序员』会以事半功倍的方式发挥能力的潜能就越大。如果手头任务比较僵化，连应该使用什么工具以及如何实现逻辑等方面有着具体指南的话，『10x程序员』用少时间办更多事情的能力就会变弱，虽然仍可以通过挖掘『本地化』设计的可能性来把工作做好，但却不能从长远考虑（包括甚至连项目的部分规范都彻底去掉，从而仍然能够以几乎相同的效果实现目标，同时实现所需的时间成本却少了一大截）的角度去实现目标的高效路径了。

在20年程序员的生涯中，我观察了一起工作的程序员同事，他们在我的指导下实现既定目标，比如给Redis项目打补丁等。这个时候，不少人会告诉我，认为我是一个干活非常快的程序员，我不仅是个工作狂那么简单，我自己也认为自己编码非常快（效率高）值得各位做参考对象。

下面是我认为的关于『10x程序员』与『普通程序员』拉开生产力差异的一些素质：

裸编程能力：完成子任务

程序员最大的限制或者说优势之一，就是处理程序实际实现部分的子任务，也就是实现函数或者算法之类的能力。

就我的经验来看，非常有效地利用必要的基本编程结构去实现东西并不是一种普遍具备的能力。在一个团队中我有时候观察到有的程序员看似非常不胜任，他们甚至连一个简单算法排序都没有考虑，但是完成的工作却要比那些理论上要高，但是他们在实现解决方案与实践方面却比较糟糕，甚至比刚毕业的程序员还要多。

经验：模式匹配

所谓经验是指一组已经过探索的、针对若干周期性任务的解决方案。有经验的程序员最终会知道如何处理各种子任务。这既避免了大量的设计工作，但尤其重要的是它还是一项针对设计错误的强大武器，而后者是简洁性的最大敌人之一。

专注：实际时间 VS 预设时间

如果不专注时间质量的话，编写代码花费多少小时都无关紧要。缺乏专注力，有来自于内外部因素的影响。对于内部原因却是拖延症，对手里的工作缺乏兴趣（不热爱的事情是做不好的）、快乐，还有睡眠不足或者家庭原因。外部原因比如频繁开会，没有独立办公室，自己经常被同事经常打断等。

试图改善专注和减少中断会对编程生产力产生非边际效应，这是很自然的。如果要获得专注，需要极端的铁腕手段。比如说我只会时不时读读邮件，但是大部分都不会去回复，另外im也是杀时间的根源。

牺牲设计：干掉5%得到90%

当不能清晰认识项目的一个非根本性目标，它可能对系统设计带来很大一部分复杂性时，或者由于某基本功能与次要功能之间存在设计冲突而导致另一个更加重要的目标难以实现时，复杂性就产生了。

设计的所有部分都不会轻而易举实现，也就是说，付出的努力与得到的好处之间是不成比例的，程序员架构师要意识这一点非常重要。

旨在取得最大化产出的项目需要完全专注于重要且可以在合理时间实现的事情上。比如说，在设计消息代理Disque的时候，在某一刻我突然意识到只要消息提供完全排序，项目的其他功能就都可以获得质的提升：比如可用性、查询 以及客户端交互、简洁和高性能等。

简洁性

简洁，这一点相当重要。但成也简洁，败也简洁。要搞懂啥是简洁，我们还是先看看复杂性是如何产生的。

我认为复杂性有两个主要根源，一个是不愿意做出对设计做出适当牺牲，还有设计行中中错误不断累积。

要思考一下设计流程，如果是一条错误的路径时，我们就会距离最优方案越来越远。初步方案设计有偏差，如果再落到能力责任较低的人手中，他没有对系统进行重构优化，而是会为了处理错误而设计出另一套更复杂的解决方案。这样，错误的每一步让这个项目会变得越来越复杂、效率变得更低下。

简洁性可以通过在脑子里进行“概念验证”的推理来实现，这样就可以让程序员对简单设计进行探索，从看起来最可行和最直接的解决方案开始，利用积累的经验和设计能力可以改进，还有一些隐藏的子系统的设计找到合理的解决方案。

无论每次的解决方案有多复杂，对于如何避免复杂性进行长时间的推敲是很重要的，只有在考虑过不同的替代方案也没有发现更好的可能性后，才继续使用原方案。

完美主义或偏向自己的设计

完美主义有两种：一种是痴迷在程序中实现可能达到的、可衡量的最佳性能的工程文化，另一种是人性特质。这两种情况是程序员快速交付的最大障碍。

完美主义以及对外来评判，会存在恐惧，也会加入一种设计偏见，心理上或者无关紧要的可衡量参数，放弃掉现有，再去做更糟糕的重新设计，而健壮性、简洁性、快速交付的能力却从没有深入考虑。

知识：理论会有所帮助

在处理复杂性任务时，有关数据结构、基础架构、对特定任务建模等算法知识，对于找到合适设计的能力会有积极影响。你没有必要成为所有技术的超级专家，但是至少意识到某问题存在大批潜在解决方案，并且知道如何去找到却是必要的。

底层：理解机器原理

当程序里出现一些bug，使用高级语言往往隐藏了一些复杂处理，大部分是没有深入理解计算机系统底层和执行任务的机制，所以造成工具或者算法存在各种问题，甚至会导致需要进行从头对项目进行重构和开发。如果你非常擅长C语言，了解CPU的原理和工作方式，对于系统内核如何运行、系统中断调用等有着清晰的认知，可以避免到后面总是遇到例外的“惊喜”。

调试的能力

发现bug并解决会消耗掉我们大量的精力。擅长定位bug位置和状态，然后在几步内修复好问题，全现了程序员的能力。写简洁的代码会减少bug的发生，写高质量的代码让心情更好，这些对于提高程序员的开发效率都会有很多的影响。

现在看来，如果一位程序员具备上面几个特质的话，能够取得10倍于平均能力的产出是完全不奇怪的。可以先从可行模型开始，一步步做出实现好的设计，且做出来的产品往往要比其它方案简单很多倍。

再次强调代码的简洁性，我将它称为“机会主义编程”。是说在开发的每一步都要对实现的功能集进行遴选，目的就是为了用最小的代价给项目产生最大价值。

（完）

作者故事：

Redis之父Salvatore Sanfilippo。生于1977年，来自意大利西西里岛（Sicily）。他的网名叫Antirez, 现常居住于Catania。

Antirez之IT职业生涯开始于系统管理员。后于Web2.0时代创立了一家Web网络公司，主要开发社交应用。之后在一次实时统计分析产品开发中，为了节省成本以及高性能扩展性，Antirez意识到需要一种支持多种复杂数据结构的内存数据库，以支持快速操作。Redis从此诞生并付之开源。之后VMWare相中了Redis, 雇佣Antirez去全职开发，而之后又衍生出Pivotal公司，Antirez继续主持Redis开发。

作者：antirez（Salvatore Sanfilippo，Redis 创始人）

URL：http://antirez.com/news/112

说明：21CTO社区编译优化，转载请注明来自本网站。