Redis之父退出项目维护者行列

Redis之父Salvatore Sanfilippo在自己的博客表示，他从来没有想过要成为一个软件维护者，现在Redis项目已经发展到一个阶段，因此他要退出Redis维护人员的行列，交棒给他的同事Yossi Gottlieb和Oran Agra，目前他还未对未来有规划，但会继续在Redis Labs担任顾问为Redis提供想法。

Redis 和 @antirez

Redis 是一个基于 BSD 开源的项目，是一个把结构化的数据放在内存中的一个存储系统，你可以把它作为数据库，缓存和消息中间件来使用。同时支持 strings，lists，hashes，sets，sorted sets，bitmaps，hyperloglogs和geospatial indexes 等数据类型。它还内建了复制，lua 脚本，LRU，事务等功能，通过 redis sentinel 实现高可用，通过 redis cluster 实现了自动分片。以及事务，发布/订阅，自动故障转移等等。

Redis 之父 Salvatore Sanfilippo，一名意大利程序员，大家更习惯称呼他 Antirez。

早在十年前，Redis 还只是一个内部项目，没有任何开源的计划。它不过是用来解决 web 应用程序扩容时遇到的一系列让人棘手的问题而已(应该是用户会话缓存)。

但 Antirez 在当时就已经是一个在开源领域活跃了十年的元老了，所以在 Redis 体现出价值之后，便将它开源了。

06

开源项目维护者的挣扎与无奈

随着 Redis 开源社区规模越来越大，越来越多的人开始在社区进行分享讨论。但这对 Antirez 来说却是一个”甜蜜的烦恼“。作为一个兼职业余的工作，Redis 开始占据他越来越多的精力和时间，甚至开始影响到了他的本职工作。并且 Redis 也变得越来越复杂。

2019 年的时候，Antirez 就曾发布公开信表示作为一名开源项目维护者的挣扎和无奈。他经过反复的思索和自我分析，坦承的表示“维护一个开源项目会带来乐趣”，但“也有消极的一面”。

当一个项目达到像 Redis 这样的流行程度，并且人与人之间的交流因为新的社交工具而变得更为容易时，作者收到的消息、issue、PR 和建议的数量也将呈指数增长。

自从 Redis 流行起来之后，Antirez 不得不进行更多查看 PR 和 issue 的工作，但这给了他很多的压力和困惑。

在 Redis 后期的设计和发展过程中，他的方式和很多用户想要的、信仰的并不一致，所以不得不在他所认为的优秀设计、工具集、开发速度、项目规模方面，和大多数用户的期望间保持平衡。

但他也表示，总的来说，能够从事自己真正热爱的事情多年，并且给他带来了朋友、认可和金钱，所以这算不上是糟糕的交易。

冒险的结束&新的开始

近日，Antirez 再次发布公开信，表示将正式退出 Redis 的日常维护工作。

“我写代码是为了表达自己，我考虑的是我编写的工件，而不只是一些有用的东西。我要说的是，我写出来的东西只是它的副作用，我的首要目标是制造在某种程度上很漂亮的东西。从本质上讲，我宁愿作为一个坏艺术家而不是一个好的程序员而被人们铭记。”

正如前文所说，随着 Redis 的流行，Antirez 的工作从建造者慢慢变成了维护者，但这并不是他感兴趣的工作。

所以，他表示将退居二线，成为只给 Redis 实验室提供产品创意和开发指导的技术顾问。虽然不排除之后接着参与开发的可能性，但不可否定的是，他现在可以抽出更多时间去做自己喜欢的事情，比如他所提到的“撰写技术博客和录制技术视频”。

Antirez 真的是一个很有意思的人。

他曾阐述过一个「十倍程序员」的概念，并为开发者提出了九条忠告，讲述了其心目中成就一名「野兽级」程序员的可贵品质；

也曾就职场性别歧视发表自己的看法，表示作为一个女性想赢得别人的尊重，那么必须很聪明能干，而不能只是因为你是个女性就该得到尊重。公平要保护的是每个个体，他们有平等的尊严，而不要把那些诸如性别、种族等歧视性因素牵扯进来。

前不久，他还用意大利语录制了视频，向大家介绍了 Redis 的技术概念，并且收到了很好的反馈。

作为 Redis 之父的他，在结束了陪伴 Redis 的冒险之旅后，开启了属于自己的、更惬意的人生大冒险。

十倍程序员是否存在？

在编程神话中，一个 10 倍效率的程序员可以完成一个普通程序员 10 倍的工作量。「普通程序员」就是指，善于完成工作但没有 10 倍效率程序员那神奇能力的人。

程序猿A

是否存在 10 倍效率的程序员，在这件事上编程社区内是严重的两极分化：有人说根本没有这样的人，也有人说事实上不仅存在这种人，如果你知道到哪里去寻找，甚至还存在 100 倍效率的程序员。

如果你认为编程是一个“线性”的学科，那存在 10 倍效率的程序员这件事看起来几乎是不可能的。一个跑步的人怎么可能跑得比另一跑步的人快10倍？在相同的时间内，一个建筑工人怎么可能建造东西的速度比另一个建筑工人快 10 倍？然而编程是一门设计学科，并以一种非常特殊的方式。即使程序员不参与实际的程序的架构设计，实施它的行为仍然需要一个实施策略上的子设计。

因此，如果一个程序的设计和实现不是线性能力，像经验、编码能力、知识和识别等无用之物，在我看来，不仅仅是线性的优势，当这些事物作用在一起时，它们的效果就远不是一加一这么简单了。当然，当程序员可以同时处理程序的设计和实现时，这种现象发生得更多。如果越以“目标导向”为任务，那么拥有10倍效率潜力的程序员为了轻松地达到目标就越可以开拓她/他的能力。

程序员应该培养的十个优秀品质

第一 纯粹的编程能力：完成子任务

A

程序员最显著的限制或优势之一就是处理实际执行程序部分的一个子任务：一个函数，一个算法等。令人惊讶的是，根据我的经验，非常有效地使用基本的命令式编程结构来实现某些功能的能力，并不像人们想象的那么普遍。在一个团队中，有时我观察到非常无能的程序员，甚至不知道一个简单的排序算法，和在理论上非常有能力、但实施解决方案的实践非常不足的刚毕业程序员相比，他们的工作往往事倍功半。

第二 经验：模式匹配

A

我的意思是一系列已经探索完成的用于大量重复的任务解决方案。有经验的程序员最终知道如何处理各种子任务。这既避免了很多的设计工作，也是针对设计错误的非常强大的武器，但反过来却又是简洁的最大敌人之一。

第三 专注：实际时间 VS 虚假时间

A

如果不考虑时间质量，那么评价花费多少时间来编写代码是不恰当的。内部和外部因素都可能导致专注度下降。内部因素是拖延，对手边的项目缺乏兴趣（你不能做好你不喜欢的事情），缺乏运动/福祉，不好的睡眠质量或者睡眠不足。外部因素是频繁的会议，没有实际办公室的工作环境，同事经常打扰等等。很自然的是，尝试改善专注度和减少中断对编程生产率将产生非边际影响。有时为了变得专注，需要采取极端措施。例如，我只会偶尔阅读电子邮件，并且不回复他们中的大多数。

第四 设计上的牺牲：删减 5%，获得 90%

A

当不愿意认识到一个项目的非基本目标占据了很大的设计复杂性，或者正在使另一个更重要的目标难以实现时，往往会产生复杂性，因为在基本特征和非基本特征之间有设计张力。设计师认识到设计中所有不容易实现的部分是非常重要的，即在努力和优势之间没有绝对的比例。为了最大限度地实现产出而执行的一个项目，将完全地集中在可以在合理的时间内实现的方面。例如，当设计Disque（一个消息的代理工具）时，在某些时候，我意识到通过为消息提供性能最好的顺序，项目的所有其他方面都可以大大提升：可用性、查询语言和客户端交互、简洁性和性能 。

第五 简洁性

A

当不愿意认识到一个项目的非基本目标占据了很大的设计复杂性，或者正在使另一个更重要的目标难以实现时，往往会产生复杂性，因为在基本特征和非基本特征之间有设计张力。设计师认识到设计中所有不容易实现的部分是非常重要的，即在努力和优势之间没有绝对的比例。为了最大限度地实现产出而执行的一个项目，将完全地集中在可以在合理的时间内实现的方面。例如，当设计Disque（一个消息的代理工具）时，在某些时候，我意识到通过为消息提供性能最好的顺序，项目的所有其他方面都可以大大提升：可用性、查询语言和客户端交互、简洁性和性能 。

第六 简洁性

A

设计时保持简洁性，这个明显的观点意味着一切。为了理解什么是简洁性，核查复杂性大多数时候是如何产生的是值得做的。我认为复杂性的两个主要驱动因素：不愿意进行设计上的牺牲以及在设计活动中累积的错误。

如果在设计过程中，每次都追求错误的路径，我们将离最优解决方案越来越远。一个初始设计错误，在不好的方面，不会导致该系统重新设计。为了应对初始设计错误，却会导致另一个复杂的解决方案被设计。因此，项目在每个错误的步骤之后将变得更加复杂和效率低下。

实现简洁性的方式是以“概念证明”来推敲，从看起来最可行和直接的解决方案开始工作，以便大量简单的设计能在程序员脑中被探索。之后，经验和个人设计能力将有助于改进设计，并为需要解决的子设计找到合理的解决方案。

然而，每次需要实现一个复杂的解决方案时，重要的是要长时间地推敲如何避免复杂性，只有在没有更好的可能性的、即使考虑到完全不同的替代方案情况下，才继续这个方向。

第七 完美主义，或者如何扼杀你的生产力和影响你的设计

A

完美主义有两种变体：在程序中达到最佳可衡量的性能的工程文化，以及作为一种人格特征。在这两种情况下，我认为这是程序员快速交付事情的最大障碍之一。完美主义和外部带有偏见的观点的恐惧带入了一种设计偏差，导致仅根据心理或简单可衡量的参数来改进设计时可选择项较少，其中诸如健壮性、简洁性、及时交付的能力往往不被考虑。

第八 知识：一些理论将会有所帮助

A

在处理复杂任务时，有关数据结构的知识、计算的基本限制和非常适合于模拟某些任务的非平凡算法将对找到合适设计的能力产生影响。成为一切事物的超级专家不是必需的，但是至少，知道一个问题的潜在解决方案是必需的。例如，应用设计牺牲（接受一些误差百分比）和清楚概率集合基数估计器可以组合在一起，以避免复杂、缓慢和记忆效率低下的用于统计整个流程中唯一的项目的解决方案。

第九 底层：了解核心

A

即使使用高级语言，程序中的一些问题也是由于对计算机如何执行给定任务的误解而产生的。这甚至可能导致需要从头开始重新设计和重新实现项目，因为在使用的工具或算法中存在着根本问题。良好的 C 语言能力，了解 CPU 的工作原理以及关于内核如何运行以及系统调用如何实现，这些可以避免糟糕的后期意外。

第十 调试技巧

A

有时候为了发现那些 bug 会花费大量的工作时间。善于获取一个bug的状态、一系列合理的解决问题的步骤、以及编写不太可能包含太多错误的简单代码的态度，这三点对程序员的工作效率有很大的影响。

—END—