软件工程师所需掌握的“终极技术”是什么？

最近，我在微博上看到@程序员邹欣老师发的一条微博 — “不少大学同学都有一个想法：先做几年技术，然后做管理；也有一些同学说：我技术不行，希望直接找到一个管理的工作，就像PM那样。请看 PM 需要什么样的能力：（链接略去）”。在读这条微博的前一部分内容时，我的第一反应是：难道同学们以为做技术管理不需要很好的技术功底？刚好在此之前，我写过《技术敏感度 — 基层技术管理者必备》一文，强调技术功底对于基层技术管理者的重要性。于是，我对该条微博评论了：“建议邹老师建议他们好好地学一学技术，技术的精进一定会让我们或多或少地贯通管理（掌握软件开发的常识）。对于真要做管理的，建议他们在以后摆好心态 — 承认自己对技术的‘无知’，以及充分尊重技术人才并放权于他们”。之后，邹欣老师帮同学们提了一个让人深思的问题 — “技术有很多，有些技术还会过时，你具体指哪些技术呢？”某种程度上，这问题可以理解为是问：“终极技术”是什么？

在执笔本文时，我总觉得以前写过类似的文章。查了一下，两年前的确以《软件开发，到底应当学什么？》为题写过了一篇博文。不过，过去的两年我又有了新的收获，或许可以借此机会再梳理一下自己的认识，以便与大家分享。

身处节奏很快的IT行业，软件工程师一定希望自己在职业发展的道路上掌握“终极技术”，以便将来即使“长江后浪推前浪”仍能获得竞争优势。掌握“终极技术”对于我们究竟意味着什么？深刻理解这一问题有助于我们在面对技术学习和技术选择时不至于迷茫或人云亦云。我认为，掌握“终极技术”的最终目的不是为了能在工作中“耍酷”（“哇，这问题其他哥们都搞不定，只有我能！”），也不是为了追赶“技术潮流”（“听说Go语言以后能替代C/C++和Java，我得赶快去学！”），而是为了高质高效地工作，因为只有这样才能提高我们的生活品质和减少浪费（浪费可能包括奢华的青春和/或宝贵的社会资源）。

实际上，我们一生都是在工作质量和工作效率的二维坐标系上“画线”。有的人一生都难以走出低质低效的困境（比如下图中黑色曲线所代表的人），而有的人却能进入高质高效的殿堂（比如下图中红色曲线所代表的人）。

明白了掌握“终极技术”的意义，那“终极技术”究竟是什么？会是C/C++、Java、Objective-C或Go等编程语言吗？当一个只精通C/C++编程语言的人加入到以Objective-C为编程语言的项目上时，显然他必须重新学习编程语言。由此看来编程语言因为对不同的项目并不具备普适性，难以拥有“终极技术”之名。对于网上不少为编程语言而打口水仗的人，我真怀疑他们将编程语言当作是“终极技术”了。 一旦知晓了“终极技术”的存在，你一定会发现，其实所谓的编程语言“优劣”跟本就不是业内的大问题。如果某种语言直接导致了项目的失败，那该语言早就绝迹了；反过来，如果某种语言直接导致了项目的成功，那世界上估计也只会有这一种语言了。因此，选择编程语言的重点不是考究其“优劣”，而是其适用性。过分计较编程语言的“优劣”其实是不成熟的一种表现。 这类人还容易犯的一个毛病是 — 生怕落后，热衷于学习新的编程语言。请别忘了，编程语言我们无论如何也学不全，即使真有人学全了，我也怀疑他所学的只是皮毛。

“终极技术”又会是Linux或Windows这样的操作系统平台吗？由于它们同样不具普适性，所以不可能有“终极技术”之实。同样地，.Net、ACE、QT等都不可能是“终极技术”。

真正的“终极技术”一定具有一定的普适性，能让我们将之运用于各种不同的软件项目。正因如此，“终极技术”具有一定的抽象性。对于软件行业来说，真正掌握“终极技术”意味着：深刻地理解软件（开发）的复杂性本质，并拥有有助于实现高质高效工作的行为（意识、工作习惯等）、能力（思维、业务、沟通）和方法（流程、工具、复用）。

由于“终极技术”过于抽象，使得我们不得不通过一些问题来间接感知。比如：

1）编程好习惯对于软件产品的质量重要吗？如果重要，如何让团队形成良好的编程习惯？哪些编程习惯算是好的？

2）软件质量的根本是什么？是设计，抑或测试？高质量的软件对工程师的工作与生活又意味着什么？

3）软件架构师重要吗？还是只是个虚职？如果重要，软件架构师需要掌握哪些技能？

4）在软件行业具有很大影响力的CMM（软件成熟度模型），其倡导用软件过程的成熟度来度量组织的软件开发能力。那为什么通过CMM最高级别认证的组织仍会开发出质量一塌糊涂的软件？如果你身临其中，能发现导致这种糟糕结果的关键因素吗？

5）软件平台与框架被广泛地认为是高效开发高质软件的方法，但为什么企业运用这一方法后，平台与框架最终却成了一个包袱？困境的表现是什么？什么因素造成了这种困境？有方法避免进入这种困境吗？

6）业内大量使用“最佳实践”这一词汇。真正存在最佳实践吗？为什么有的“最佳实践”在组织中却无效？

7）……

这些问题大多是开放性的，而且不少问题既涉及管理域，又涉及技术域。面对这些问题的关键不在于其是否有标准答案（或许根本没有标准答案），而在于我们是否为之痛苦过、思考过，并形成了自己的想法。要知道，这些想法就是我们在工作中面对选择时用作决策的依据。如果从来没有这类苦恼，很难想象我们真正掌握了“终极技术”。值得一提的是，这些问题只是基于我自己肤浅的认识所提出的，我相信读者还有很多类似或其他的问题。

如果将软件（开发）的复杂性比喻为一头大象，那么我们每一个人或许是正在摸象的又瞎又聋的人，我们穷一生通过“摸”的方式，在头脑中构建“象”的模样。这个比喻间接地告诉我们，“终极技术”并非是某种一成不变的内容，其中更涵盖有每个人根据自己的阅历所总结出来的在高质高效工作道路上成功应对困境的方法和信念。

“终极技术”一定是通过掌握象编程语言等非“终极技术”而最终掌握的，也需要我们通过经受软件项目的痛苦磨砺去沉淀。在没有掌握“终极技术”之前，请不要停留在编程语言专家、Linux内核专家、.Net专家这样的光环之下，继续探索，前面还有更大的舞台等着你！在掌握“终极技术”的职场旅途中，我们得先认识到一点：就技术内容而言，职场首先比拼的并不是智商，而是我们的坚持与良好的工作习惯。工作中的很多道理我们都懂，但就是不能坚持做到深究，也难以通过坚持克服陋习去形成更多的好习惯。在掌握“终极技术”的道路上，我们一定会看到很多不尽人意的内容，也会面临不少困难与挫折，即使理智上悲观，但我们在行动和意志上一定要保持乐观（注：Antonio Gramsci的原话是“理智上悲观，意志上乐观”）。