《房间里的大象》来自Apache软件基金会副总裁Niclas Hedhman的分享

致谢：

《房间里的大象》是Apache软件基金会副总裁Niclas Hedhman在2016中国开源年会上做的演讲。

易软天创的小伙伴参加了此次年会，听了这个演讲后，产生很多共鸣。

在征得了Niclas Hedhman先生的同意后，将此演讲使用的PPT翻译成中文，分享给大家。

在这里，再次向Niclas Hedhman先生表示感谢！

《房间里的大象》PPT内容如下：

作者： Niclas Hedhman，翻译：滕菲。

大家好，我的名字是Niclas Hedhman。我是Apache Software Foundation长期贡献者。

作为一个软件开发人员，我已经工作了32年。多年来，我做了许多观察。

最新的观察是关于一件事，这件事是显而易见，我们却没有注意过它。

“房间里的大象”是英语中的一种表达，指的是那些没有人敢谈论却又很明显的事情。

这个演讲，我想谈谈软件行业里没有人敢谈论的话题，但却能把我们带到另一个层次。

前面提到了我已经做了观察。我们都会观察。

几乎每个人都看到过漂亮的代码。这些代码简洁明了，而且很强大的。这种代码易于理解，易于使用，易于扩展。我们可以很快地完成工作，把事情做好。

然而，如果我们问人们，他们是否在漂亮的代码基础上工作，大多数人说没有。

那么，这个代码是从哪里来的呢？

嗯，很少有开发人员能写出这些漂亮的代码。

另一方面，烂代码随处可见。
我们都见过烂代码。
我们中有些人每天都要和烂代码作斗争，我们都为写出更多的烂代码而内疚。

但是为什么？为什么你要写烂代码？你知道这代码很烂，你还要写。为什么？这是为什么？

我们会听到这样的话，这代码已经很烂了，我没办法改善，因为没法测试，因为代码太复杂，因为做需要的改变太危险了。

我现在很忙。交付期限快到了，等有时间我们会解决这个问题的。现在，我们需要把握重点，把这个问题先搁一搁。

嘿，我觉得这代码也没有很烂。我的队友们都很不高兴，但我认为他们不够聪明，无法欣赏这代码。

我要说，这都是狗屁。那些都是借口，因为不然我们也受不了自己这样。

我们怎么能明知做不好工作，却不感到羞耻，为什么不去换份工作呢？

我的推断是，还有更加深层次的原因，是我们行业存在已久的危机。

我觉得这非常令人不安。

有没有人能告诉我这是什么？

这是全世界程序员数的增长曲线。具体的数字不重要，尽管据估计人数在50-100万之间。
重要的是，程序员人数在每5年左右就会翻一番。从1950以来，这种增加几乎不间断的。每5年，世界上的程序员的数量增加了一倍。

关于这种指数增长，我们能看出些什么？有两件事。好的是，这种增长不会永远继续下去。因为地球上没有这么多人。坏的是，这些程序员中，有一半都工作经验都不足五年。

实际情况可能更糟，因为还有很多程序员将在未来在10-15年离开这个行业。

所以，我们行业非常缺乏经验，而且一直缺乏经验。

更糟糕的是，由于技术的大环境变化如此迅速，在一项技术过时之前，没有足够的时间来积累经验，然后所有人又开始使用另一个技术了。

这导致同样的错误是一次又一次的循环发生。

大多数程序员不会发明新技术供别人使用。我们使用热门的技术。

我们相信，其他人已经知道何种技术适合我们。我们也不会动脑去思考。

我再说一遍，我们不会批判地思考，并且我们想信仰宗教信条一样，相信别人告诉我该怎么做，我就应该怎么做。

让我们来看看我们的行业的神话。这神话有很多。

由于我们的行为像一个宗教教派，也产生了许多神话，有的是偶然，有的是刻意而为。

神话是由特定的一类人创造和传播的。我们很容易受到我们所尊重的人所说的话的影响。供应商试图向我们出售产品和服务。同样，会议上的发言人，我们阅读书和博客的作者，他们是向我们卖他们的书，网站或服务。在工作中，我们听比我们更资深的人的话，这些人通常是那些有一些成绩的同事。但如果这是一个大公司，那么这些同事的话就会涉及办公室政治，或有为了赢得声望的因素，我们应该对这些人的话产生质疑。

让我们看看业内典型的神话，那些所谓的常识。

神话一 软件很容易修改 我们生活在这样一个概念里，软件是....软的，灵活的。

打几个字，我们就可以改变它，让它做一些完全不同的事。

重新设计的电子产品需要几天的时间，而软件只需要几分钟。

但是，嘿…现实是很残酷。它不是神话，而且会反击。

大多数软件不仅是难以改变，而且一旦用了就往往不能结束。

一旦写好软件，部署好，要想摆脱它，门都没有，无论这软件用起来多么琐碎或一无是处。

这种情况在公司管理中普遍存在。

如果我们需要多花一倍的精力做某件事，我们就多招一倍的程序员。

这肯定行。

《人月神话》（The Mythical Man-Month）是1975年出版的一本书。

40年前，作者Fred Brooks指出，增加人手到一个落后于计划进度的项目里，实际上会使项目进度变得更慢。

最终，花费在沟通所需的时间将比每个人有的时间加在一起还要多。

大公司的经理们的另一个最喜欢的神话就是是，程序员是可互换的零件。

如果一个程序员离开了，我们就从大街上找择一个新的，代替他。

但是那根本行不通。软件知识不在代码里，而存在于写代码人的大脑里。

如果你以前抢修过别人的代码库，而这写代码的这个程序员没有给你任何工作交接，你就知道我在说什么了。

如果写代码库的人离开了，则需要两个新人来代替他，这两人可能需要一年的时间来搞明白这个代码库的作者写的到底是什么，也有可能永远都搞不清楚。

这是我的最爱的神话之一。

如果不是这些抽象概念，我们不会有互联网，也没有网上那些很棒的网站。

如果我们必须为处理器写二进制指令，就有麻烦了。

编程语言，协议，数据格式，框架，还有更多的抽象的概念帮助我们完成工作。

但大多数抽象概念都是在我们写的程序中产生的。

我们创造出的抽象概念只是小聪明，概念不够清晰。

我们也没有很多创造抽象概念的经验，所以我们创造出的是混乱。我们创造的抽象概念往往很糟糕，一片混乱，不利于项目的完成。

很多人兜售各种方法论。

20世纪80年代后期使用的是用例对象方法，然后是理性统一过程和许多其他所谓的计算机辅助软件工程的方法，最后是统一建模语言UML。

Kent Beck介绍了到极限编程方法，这是第一个敏捷方法，是一个反对瀑布式的方法。

近10年间，Scrum，看板和其他方法备受吹捧。所有这些都方法都承诺解决软件这一复杂工作。

我的观察结果是，没有一个方法像宣传的那么好。几乎所有的软件项目都依赖于大神。

能完成项目的人，无论用什么方法，都能完成。对于新的项目，大神们擅长的是开始着手做。

在维护或改进代码库的时候，大神是那些工作中不介意遇到糟糕代码的人。

回到我们的行业。

我们可以以以下方式对我们的行业的程序员进行分类，天才，良好，一般，差和糟糕。

让我们看看每一个的特点。

天才程序员写的代码库很简单，可重复使用，且功能强大。

他们坚持不懈，持续发展，对代码库进行小而有规律的改进，添加新的功能。

他们写了足够多的相关测试。他们往往很谦虚，知识渊博。

他们也不完美，经常要从头开始重写整个库。但他们能写出更好的代码，而不破坏兼容性。

良好开发人员写代码库比较复杂。

通常他们留下了很多未完成的地方。因为他们不会在一个库工作很长时间，很快他们就会开始做另一件新人兴奋的事情了。

他们写的代码库很快变得陈旧，没有人知道如何操作它，而测试它则需要写太多的代码。

良好开发人员对自己和自己的工作感到自豪，但是他们的代码不能重写，因为这些代码写得没那么好，缺乏测试机制。

一般的程序员通常是大公司的维护软件的大神。

他们不计一切代价解决错误，砍掉新功能。如果测试中断，他们只需禁用测试，因为交付代码的时间到了。

他们也不喜欢与那些良好的开发人员工作，因为这些人会留下存在依赖关系的抽象概念和代码库。

这些东西用起来很不方便，而且有很多错误，还没有文件记录。

较差的程序员不关心任何东西。他们只会工作，写代码，回家，然后重复这一过程。

他们永远不会学习，他们不听取别人意见。即使告诉他什么是好的代码，什么事糟糕的代码，他们也不能分辨出来。

他们不应该成为程序员，一般也不会一直做程序员。

糟糕的程序员没有比较差的程序员那么糟糕，因为他们和他们周围的人都知道意识到他们没有经验的，代码写的不是很好。所以他们想学习，渴望成为更好的程序员。他们也往往会过渡成为良好的程序员，但有的也会变成比较差的程序员。糟糕是一个短暂的阶段，没有什么可以担心的。

这给我们带来了下一个神话。

如果我们问程序员，他们属于哪一类。

如果他们没看过这些类别的定义，那么我们将得到这样一个结果，60%的程序员认为自己是属于天才和良好类，只有30%左右的人认为他们是一般的程序员。

但依我的经验，统计数字应该是这样的。

极少数的是天才程序员，有一小部分的良好的程序员，大量的程序员属于一般、较差的程序员。好好思考一下吧。

所以，当天才程序员向我们展示其简单而卓越的杰作，有着漂亮的设计，简洁的抽象，简单易用……

我们就认为“我可以做到”。

在希腊语中，Primus Inter Paris意思是第一名也是平凡人。

这种观点认为真正优秀的人仍然只是我们中的一员，没有什么不同，我们都可以做到。

当我们看到别人写的漂亮代码，觉得很稀松平常。

但我们这些普通人太愚蠢了，看不到自身的局限性。我们知道最漂亮的代码长什么样，知道这是如何使用，但这并不意味着我们可以自己写出这种代码。

虚幻的优越感和达克效应分支理论告诉我们，我们太愚蠢了，却不知道我们是多么愚蠢。

我们对自己的能力有信心，写了那些在正常情况下几乎不能运行的复杂软件，这些软件即使在特殊情况下也无法运行。

我太愚蠢了，我写不出好代码。

所有人，现在，说出来……

这就是房间里的大象。

当然有问题。首先，是经济上的问题。

招更多的程序员，花费是更昂贵的。

招更多的人参与写一个代码库，会使代码库变得混乱。

银行有大量的程序员，只是为了保持程序可以运行。要改变代码库，这个过程是缓慢的。

如果我们看看所谓的互联网公司…这些人在做什么？互联网的效率是减少需要的人的数量。

其次，当前形势有社会影响。

不快乐的程序员倾向于改变工作。

我想说明，大多数情况下，新来的人会使情况变得更糟。

另一个恶性循环，是这种情况像滚雪球越滚越大。我们应该对自己的工作感到满意。当我们去上班时，应该感到高兴。

员工高流动率的另一个方面是，许多程序员为了逃避写代码，去了其他类型的工作岗位，如管理，业务分析师，甚至一些完全无关的专业岗位，因为他们做程序员不快乐。

这导致程序员岗位从业人员经验不足，情况变得更糟。

这个演讲内容非常消极，甚至对许多人来说是个的人身攻击。但是有什么解决办法吗？我想会有解决办法，但是是在遥远的未来。

一些天才会想出软件开发的新模式。我希望它是从根本上不同于我们现在的模式，类似于十八世纪将蒸汽机的引进矿业的发展。

也许人工智能可以用一个完全不同的方法来写软件，从而让我们停止写糟糕代码。谁知道呢？在那发生之前，我想我们都停留在了计算的青铜时代。

用手写代码写出每一个细节，但没有创造出可以传承知识，所以我们无法提高集体技能。

我想给你这个建议。

接吻原理-保持简单，直接（The KISS principle - Keep It Simple, Stupid.）。

当你写代码时，记住这是一件事。不要做额外的抽象。避免概括。避免继承（inheritance）。

不要写你认为你将来可能需要的代码。当没有更多的代码可删除，那么工作就完成了。

即使你正在工作的代码真的很混乱，很糟糕，请不要让这种情况变得更糟。

即使代码很糟糕，如果你改善一点点，就会变好一点点。如果每个人都一点点，最终代码会变好很多。还有，不要让你的队友让把代码搞得更糟糕！。