什么是技术 技术人最重要的能力是什么？

标题地图:来自zoommy

关于这个话题，我曾经写过一篇文章《程序员的真正价值》，后来发表在《跨越国界》一书中。最近InfoQ推了华仔的一篇文章，深入探讨这个话题。但是由于种种原因，这篇文章发表后不久就被删除了。很多读者告诉我想看，我就在MacTalk上转帖，做了一些修改。

注:华仔是李云华极客时代《从零开始学建筑》的专栏作家。他的专栏已经被17000人研究过了。

俗话说“文不为先，武不为后”，技术是一种“文”的能力。我们很难直观地看到一个技术人员的实力。但无论是公司招聘的面试，还是公司内部晋升的面评，都需要在相对较短的时间内快速判断一个技师的实力。正是因为技术实力的评价没有绝对客观的标准，很多时候你会听到类似的吐槽:

XX在我们组的技术实力不如我。即使他升职了，我还是被刷了。评委真是~！@#￥……

面试官问了什么样的问题？我基本没问我知道什么。我感觉他根本不会考察我的技术实力...

听说算法和数据结构最能体现程序员的实力。我想啃《算法导论》(但是吃完就算了)...

……

类似的问题和吐槽还有很多，都可以总结为一个问题:当我们谈到技术能力的时候，我们在说什么？

有人认为技术实力意味着算法和数据结构非常强大...

有人认为学习过Linux内核源代码，简单理解MFC的人就是技术强的人…

有人认为会写C++的才是真正的技术大师，因为C++对象的初始化有n种方式...

有些人认为技术专家必须熟悉业务...

有人认为是技术牛贡献了开源项目代码…

有些人认为只有建筑师才是技术牛...

我相信1000个人眼中有1000个哈姆雷特，1000个程序员心中有1000个技术公牛。

技术力量的本质

感谢我的工作岗位，让我积累了丰富的评估技术人员实力的经验(包括踩坑的经验)。首先是招聘。前后采访了几百人。技术范围包括服务器、安卓、iOS、前端，既包括应届毕业生，也包括腾讯的T4大牛；其次，评委升职。作为通过专业水平提升的评委，他们面试了几十名获得提升的技术生。他们见过各种各样的案件，也和其他法官交流过。有时候，他们甚至会为某个学生是及格还是不及格而发生争执。通过这种不断的实践、思考、踩坑、交流的过程，逐渐形成了一套完整的方法论。接下来我就来说说这套方法论，分享一下我如何判断技术人员的技术实力。

简单来说，判断技术实力的一个普遍原则就是，技术实力是指解决问题的能力！

我们将细化这个原则，并得到几个详细的规则:

1)没有通用技术

简单来说，问题是领域相关的，技术是用来解决问题的，所以技术是领域相关的，没有一刀切的技术。

有网友说:高斯林来做iOS开发，几分钟就把iOS开发者都干掉了，因为最有经验的iOS开发者只有10年的经验。我觉得这是不可能的。iOS开发领域面临的问题与Java编程语言开发面临的问题有很大不同。当然，如果高斯林做了几年iOS开发，可能确实会超过很多iOS开发人员，但也不可能一开始就干掉做了7~8年的iOS程序员。

2)技术只有能解决具体问题才有价值

技术只有能解决某个领域的问题才有价值，否则知道某个技术是没有用的；掌握了某项技术却没有在当前领域使用，这项技术在当前领域没有价值。

当然，有一些技术目前看起来对目前的领域可能没什么用，但以后可能会用到。因此，技术人员需要储备一些目前暂时无用的技术来拓宽自己的技术视野，比如目前火中的人工智能和区块链技术。但是要注意“可能”这个词，需要技术人员自己判断和平衡，不能以技术储备为借口什么都储备。比如数据库开发工程师至少几年不需要储备VR知识。

3)问题的复杂程度决定了技术实力的高度

问题的复杂程度不同，复杂程度越高越难解决，相应的技术强度要求也越高。

我们用这个原理来分析对上述各种技术优势的理解:

技术实力意味着算法和数据结构非常强大

很多面试官喜欢让面试官当场手写冒泡排序、快速排序、链表等代码来判断面试官的技术实力。但是，我们可以通过分析这个原理发现，这不能评估技术实力。如果招聘一个会手写快速排序的面试官，你会让他用自己的快速排序解决什么问题？在大多数场景下，新员工似乎不可能写一个快速的排名来解决问题。

当然，肯定有人会说，“我考核面试官的技术基础和思维能力。”这个说法是对的，但是如果是为了这个目的，现场手写快速排序的面试方法是错误的。如果是考察技术基础，评估的范围应该是算法的基本逻辑、优缺点、适用场景，因为这些技术点在后续具体应用中选择合适的算法解决问题时非常有用；如果是考察思维能力的话，考核的方式应该是给出一个具体的算法应用问题来看面试官的分析和思考过程。比如我在知乎上发了一篇我们业务用的“如何快速计算你的朋友和你共同的朋友的数量”的论文，在评论里意外的引起了很大的讨论。有兴趣的朋友也可以试试。

学习过Linux内核源代码，简单理解MFC的人，是技术比较强的人

国内技术人员(不知道国外有没有类似的)对底层技术有偏见，认为只有懂底层技术的人才是真正的技术大师，否则干脆调用API来完成自己的功能。我也不例外。我曾经说过“程序员的三大漏洞:Linux内核源代码、编译原理(龙书)、简单说MFC”，我都跳过了，花了很多时间，收效甚微。事实上，通过分析原则，我们可以发现这种说法是站不住脚的。如果我们从事Linux内核开发，编程语言开发，MFC框架开发，这些技术真的可以解决问题；然而，如果我们不在这些领域发展，这些技术不能帮助我们解决任何问题。我没有看到任何需要通过编译原理技术解决的Java编程问题，也没有看到任何需要通过研究Linux内核源代码解决的数据库问题。当然，并不是说这些问题一定不存在，Java语言本身一定有bug，但是这些问题需要Java官员来解决，我们在应用中也不需要亲自去解决，否则效率会很低，个人爱好也是我们力所不及的。

会写C++的才是真正的技术大师，因为初始化C++对象有N种方式

这是程序员之间永恒的话题，哪种语言最好，哪种语言最好。有两个著名的词干:PHP是世界上最好的语言，C++是世界上最好的语言。C++语法真的很复杂，功能也很强大，所以能完全掌握C++的程序员应该只有极少数，但这是不是意味着掌握C++很牛逼？也不尽然。我们来分析一下原理。如果用C++做游戏引擎或者高性能中间件，C++确实能解决问题，但是如果我们用的是安卓手机信息app，C++能解决什么问题？自己写一个加密库可能比系统有更多的库漏洞，所以用C++自己写SQLite似乎没有意义。

建筑师是技术公牛

架构师几乎是每个程序员的技术梦想。能够成为一名架构师(真正的架构师，而不是PPT架构师)必须有很强的技术实力，这是无可争议的，但问题是，如果你不能成为一名架构师，你就不会成为一名大的技术专家。当我们分析原则时，我们会发现事实并非如此。建筑师不是万能的。他解决的主要问题是系统的结构设计。还有一些问题是建筑师无法解决的。比如MySQL 5.6优化了一个伪共享问题。性能提升50%(http://www . cis . upenn . edu/~ delo zier/docs/TMI _ micro _ 2017 . pdf)。这个问题的发现和处理并不比架构设计简单，能发现和解决这个问题的技术人员非常厉害。

以上分析了几个典型的误解，其他观点，这里只贴一个简单的回答，你可以应用这个原则来分析具体原因，基本接近:

“技术大师必须熟悉业务”——正确

“是技术牛贡献了开源项目代码”——错误

技术实力详解

在了解了评价技术实力的基本原则后，我们知道，要解决的问题的复杂程度越高，技术实力就越高。在此基础上，我把技术实力分为两类六类:

硬实力:真正解决问题的能力，别人看得见的能力，技术实力按“点、线、面、体”四大类逐步上升；

软实力:比硬实力更强大，但也更虚。简单来说，要解决问题，首先要找到问题，但很多时候问题不是一目了然的，需要有一定的技术洞察。软实力主要包括两个核心能力:发现问题和技术创新

硬实力

我把技术硬实力分为点、线、面、体四个层次。技术水平依次提高，解决问题的复杂程度越来越高。下面详细解释。

[技术要点]

“点”是用于解决特定问题的特定技术，例如使用JDBC从数据库中读取数据，以解决因断电而导致的数据丢失问题；使用Java多线程的目的是解决大量用户并发访问的吞吐量和延迟问题。

掌握了技术要点之后，就可以开始开发基本的业务功能了。

[技术路线]

一条“线”是一系列相关的技术点，每一个都是为了解决某个问题而设计的。例如:

1)为了完成一个用户请求，开发框架必须首先具备路由路由器的功能。路由到特定控制器后，控制器执行业务逻辑处理。在处理期间，可以使用JDBC来读取数据，并且可以访问Redis读缓存。这些技术系列中的每一个都解决了一个问题，并且通过将它们串联在一起完成了一个业务功能处理过程。

2)为了定位一个在线Java服务器响应慢的问题，需要使用tcpdump捕获包，使用Java工具检查jvm状态，使用mysql命令行或工具检查数据库状态，使用解释分析可疑的sql语句。

掌握技术路线可以完成某个业务功能的全流程设计开发。

[技术方面]

“面”是某一类相关技术线的综合。例如:

1)Java开发是技术方面，包括多线程、JDBC、文件读写、JVM调优、JVM工具等技术路线；

2)高性能开发是技术方面，包括:数据库分区、缓存、多线程、HTTP优化等。；

3)数据库维护是技术方面，包括:数据库调优、数据库问题定位、高性能数据库表设计等。

要掌握技术方面，你已经是某个领域的专家了。简单来说，你可以解决这个领域的任何问题。

[技术机构]

“身体”是多个技术方面的综合。

最常见的“身体”是建筑设计。对于一个大型企业或者系统的架构师来说，他需要掌握几个技术方面，然后进行设计和权衡。例如，一个后台架构师需要掌握Java、数据库和网络的技术方面，以及业务领域的知识。

建筑设计是横向技术方面的综合，我称之为广度技术体；还有纵向技术方面的综合，我称之为深度技术方面。比如Java开发工程师掌握了“多线程、JDBC、文件读写、JVM调优、JVM工具等”当他们达到技术水平时。如果需要进一步提高Java领域的技术，需要了解操作系统和硬件(CPU、内存、磁盘等)。)，从而更好的解决一些复杂的问题，比如Disruptor高性能并发框架的设计。

掌握了技术体，就可以设计架构，或者成为某个领域的资深专家，解决领域层面的复杂问题。

软实力

软实力包括发现问题和技术创新。

[发现问题]

有些问题比较明显，比如在线故障，系统性能不达标，系统性能需要达到5wqps但是有些问题并没有那么明显，不可能一眼就看出问题在哪里，是技术问题还是管理问题。

例如，我们遇到了团队之间协作开发的低效率。每次我们开发一个业务功能，我们都需要几个系统R&D人员来讨论接口协议、接口数据格式、接口安全加密、业务逻辑等。每个人都很用心，但似乎都是必须的。为了提高团队之间的效率，项目经理制定了规范、流程、模板等。，但效果最终很小。那后来是怎么解决的呢？引入服务中心完成系统间的同步接口调用，引入消息队列完成系统间的异步消息通知，大大提高了系统间的协作效率。以前开会讨论事情要开几个小时。现在只需要把界面传递的数据内容说清楚就行了，甚至不用开会，两次调研讨论也差不多。

另外，问题的根源往往隐藏在很多表象之下。不解决一个根本原因和一个表象问题，你会得到暂时的平静。过了一段时间，又会出现另一个问题，一遍又一遍的重复。

比如我们以前有一个系统。今天交换机故障导致业务问题，明天系统bug导致业务问题，后天机柜断电导致业务问题，也是被黑客攻击。这些问题看似独立，问题的发生也感觉是偶然的。按照一个问题解决一个问题没有错，但是一年到头，生意上的问题很多。怎么解决？经过分析，我们发现根本原因是业务需要异地居住，架构是两个机房的单中心。我们需要做的不是回避每一个问题(其实是不可能回避的)，而是在问题发生后迅速处理。所以通过改造建筑异地居住，改造后还是有各种偶发性的问题，但是对业务的影响很小。

发现问题的能力主要来源于经验，包括成功的经验，踩坑的经验，参考别人的经验。所以要想培养自己这方面的能力，就要多思考，多总结，多学习，多参与行业交流。

[技术创新]

达到这个水平，基本就是业内大神的水平了。说实话，我没有经验，只能佩服这些大神。

例如:

1)当时贝佐斯要求对亚马逊的系统进行服务。后来有哪位大神想到这个能力可以打开，转换成“云计算”？

2)为什么阿里巴巴云王健博士在大家都不看好的情况下坚持云计算是未来？

3)3)Google如何在解决大数据问题时提取三篇论文，开启大数据时代？

技术实力案例点评

有个面试官面试Java P7，其中一个项目经验很棒:XX架构重构，性能提升10倍。因此，我对这个项目的经验和结果进行了深入的调查...

以下是我们的一般对话流程:

我:请简单介绍一下这个项目重构。

脸:我们的一个业务跟运动会有关。每次重点比赛前的业务访问次数是平时的10倍以上。原系统太大就卡，用户体验很差，需要重构。

我:具体怎么做？

Face:通过引入mc cache，我把原来直接访问数据库的操作改为先访问cache，性能提高了10倍。

我:为什么会想到引入mc？

脸:(被卡住了，有点惊讶于自己的问题)...我查了网上的资料，很多人说mc可以大大提高性能，用了之后效果真的很好。

【点评1】这是典型的“代码靠复制，方案靠搜索，效果靠试用”。面试官看到一个问题，但没有分析思考，然后在网上搜了一下方案，看到很多人说引进mc可以解决问题。关键是最后好像真的解决了，让面试官自我感觉良好。

我:mc能大幅度提升性能是什么原理？

面:缓存访问快，数据库访问慢。

我:mc的性能和数据库的性能有多高？

脸:……(思考10秒)不好意思，没研究过。

[点评2]这是一个典型案例，但不知道为什么，可以用开源的解决方案，基本测试和原理研究都没做过。

我:没关系。换个问题吧。你的系统改造后会用到多少台机器？比重建前少了多少？

表面:机器数量100台，与改造前相比没有减少。

我:哦，有100台机器，每个QPS只有300多台。我觉得你的生意不是很复杂。为什么这么低？

面条:...(卡了10秒)这个...300多的QPS不算低吧？

我:你有没有分析过每一个请求的整个流程的每一个阶段的性能耗时？瓶颈在哪里？

脸:(卡了5秒)还没分析？

我:那你觉得为什么引进mc会有效？

脸:……(卡了10秒)我想大家都说引入缓存可以大大提高性能，最后的效果真的很好。

【点评3】这就是知道技术点，不知道技术路线和技术方面。至少在技术线层面分析系统性能问题是合理的，需要分析每个请求每个阶段的时间消耗和原因；也可以是技术层面，比如分析数据库设计，服务器负载均衡等。也可以是技术层面，比如架构是否合理，一个子系统是否可以拆分引入消息队列等等。

我:好吧，我们换个问题。如果再优化系统，你觉得你能做什么？

脸:……(思考20秒)我觉得目前的系统性能已经足够了，应该没必要优化。

【点评】他调查的是发现问题的能力，却找不到。事实上，如前所述，100台机器是个问题，太低的QPS也是个问题，但因为他没有经验，他看不到这些问题。

可惜最后面试官面试失败了。