聊聊我眼中的普通码农和技术大牛的区别

最近几年，IT行业中的各个群里突然流行了一个词——“大牛”。有些人因为在学术界发了很多论文而被称之为牛；有些人因为在群里努力帮助大家解决问题而被称之为大牛；有些人因为写了一本技术的书而被称之为大牛；有些人因为开源了很多技术知识二被称之为大牛；还有些人因为代码能力强被称之为大牛……今天我们不聊其他的大牛，就来聊聊那些因为代码能力强而被称之为大牛的人。

10年前的一个案例

实际上这个代码能力强的大牛一般是要和普通的码农来对比，与普通码农相比，这些代码能力强的人，到底强在哪里？首先来给大家讲一个在我身边所发生的真实的事件。

大概是10年以前，那个时候单片机非常流行，很多人都喜欢在单片机上开发一些应用，但是单片机有一个问题，就是存储相对来讲不是很通用，导致很多时候对于单片机的存储需要写很多代码进行处理。那个时候虽然已经有了sqlite数据库，但是业内应用的并不是很多，很多时候大家都是使用基于内存地址的存储方式进行存储。当时我们就在想，能不能自己写一个简单的数据库，用来存储我们所需要的数据（当时我们数据传输使用的是xml格式的数据），于是我们团队里的一个大牛就决定试一试，于是他花了大概不到一周的时间，使用C语言写了一个相对比较简单但功能却非常全的XML数据库。大家可以想象一下，四五天写出的数据库支持自定义的查询语言（类似于sql语句），并且还能支持各种遍历和节点存取操作，且单次查询运行效率也是在10ms以内，这即使是放在现在，也是一个比较艰巨的任务，更何况是10年以前。

现在事情过去差不多10年的时间了，我们来分析一下为什么他就那么牛，为什么他就能成为技术大牛呢？其实要想分析他之所以能够成为就是大牛的原因，我们应该把这件事情从后向前来推一推。当时他是使用C语言写了一个简易的XML数据库，并且这个数据库的运行效率非常高，要想达到这一点，首先要做到的就是对于C语言的各个函数的熟练程度，已经对于数据结构和算法的熟悉程度。大家都知道，想要使用C语言来写出一个比较完整的商业级的应用绝非易事，尤其是C语言中对于指针的处理更是令许多同学望而生畏的，但是我们也知道，正是由于C语言中的指针，才使C语言对内存操作更加便捷，使得可以更加高效的开发出具有商业级别的项目出来。

另一方面，要想把这个功能完成，还需要对整体的系统底层有着比较深入的研究，并且对内存的优化足够了解。在业务层面，还需要对XML格式的解析，存储，以及与内存地址的交互有着深入的了解，才能将这一套完成。

最最重要的，实际上还是对于代码的能力，也就是我们所说的coding，其实在这里，coding的能力也取决于两个方面，一个是对于整体语言和系统底层架构的熟悉程度，另外一方面就是对于整体问题的分析和解决思路。而这些问题，往往是普通程序员和大牛程序员的区别所在，接下来，我们就来对这几个方面做一个简单的分析。

对于数据结构与算法的认知和使用

对于数据结构和算法的认知和使用是普通程序员与大牛程序员最主要的区别。很多人都会认为，数据结构和算法，我会啊，大学学过，你让我写一个单链表，写个二叉树，手到擒来。实际上，这个是一般人对于数据结构和算法的看法，大多数人都会认为，我只要对各种数据结构和基础算法懂就可以，让我写的时候我随时可以写出来就ok，这也是初学者最容易犯的问题。

因为在实际的工作和工程化过程中，没有人会告诉你，我要用某一个算法来解决某一个问题，而是给你一个需求，然后告诉你这个需求里面的一些必备要求，比如响应时间在30ms以内，支持1000人的同时访问等，然后让你自己来实现，具体用什么算法自己来决定。

实际上这类的问题非常考验算法同学的基本功，对于算法同学来讲，最基本的基本功就是数据结构与算法。在什么时候，用什么排序算法，针对于大数据集和小数据集，用什么样的算法能够使其效率最高，实际上都能看出来一个人的代码水平。但是针对于大部分程序员来讲，在真正拿到项目需求时，往往就会忘掉这一点，而是先实现了再说，最后的结果是实现了，但是代码的质量以及效率经常是惨不忍睹。

对于数据结果和算法的使用，一般是在长期代码的开发过程中总结出来的，这个真的是需要不断的总结积累才能够慢慢锻炼出来的一种能力。很多时候，我们只是为了完成需求而完成，只要这个任务能够运行出来就万事大吉。

记得在很久之前，有一个是笑话但又非常真实的故事。就是在acm竞赛中的一些练手题目中，给定一个最大数字，可以根据这个数字输出指定的图形，就像下图这样。

其实这道题正常应该是用循环来做，但是有些人说，我直接用print加上空格也能够实现。确实，针对于这个问题，实现的方式有很多，但是往往最方便的只有一个。当然，这个例子有些夸张，但是我想借此来说明的一个问题就是，数据结构与算法的思路，是看出新手和大牛的关键点所在。

我们要学会，在任何时候，都用算法的角度去考虑问题，怎么样优化才能够使算法最优，效率最高。而不是仅仅把这些都停留在刷LeetCode题的阶段，要把它们运用到实际的项目当中，只有这样，我们才能够向大牛的方向不断进步和提升。

解决问题的思路

解决问题的思路也是决定着大牛还是普通程序员的关键因素。从解决问题的方法和思路中往往能够看得出一个人的能力。所谓的解决问题的思路是指当程序遇到bug了，或者遇到一个新的需求，用什么样的思路快速的去定位到问题，并解决问题的过程。

其实这类事情在一个企业中非常常见，在任何时候，我们都不能保证我们所写的代码没有任何bug，也不能保证每一个新的需求我们都能快速的写出解决方案，很多时候，我们都需要经过自己的思考，来寻求问题的最优解。我曾经遇到这样的一个员工，当时他在我的组里负责推荐系统的一部分算法业务，突然有一天，测试人员跟他说：“目前算法所跑出来的结果和实际的结果对不上，你看看是怎么回事？”于是这个同事拿到这个测试反馈之后，就开始找问题，找了一上午都没有找到是哪里出了问题。于是他过来问我，说：“黄老师，这个我找了一上午，感觉没问题啊？但是为啥就是对不上呢？”于是我又让他重新演示了一下找问题的方法，最后我发现，是他找问题的思路出了问题。

他是根据现有的问题去结果里面找这个问题为什么会出现，用这样的方式去找，很容易把自己绕进去，最后总觉得是没有问题的。但是实际上，我们在解决问题的时候，需要跳出思维的定式，首先分析产生问题一般会出现在哪几个阶段中，然后再从这几个阶段中观察这几个阶段的输出，通过观察输出就可以看到，在哪个阶段的输出是正确的，在哪个阶段的输出是错误的，然后再去从错误输出的阶段中去寻找问题所在，把整体的业务流程理清，从而解决问题。

实际上，很多时候当我们遇到了程序的bug时就会很慌，感觉程序出了bug了，自己有很大的责任，心态乱了，心太乱了之后，就会越来越着急，越着急就越找不到问题的所在，最后就会无功而返。这其实是很多程序员的通病，归根到底就是解决问题的思路不对。

其实程序是什么？说到底，程序是遵循着既定的业务逻辑的，也就是说，当我们给定了一个程序的输入，我们就应该能够预判出一个程序的输出，所以在IT界常常有这么一句话：“程序是不会骗人的”。因此，当我们遇到问题的时候，千万不要乱，只要思路清晰，掌握好程序中的关键阶段，那么定位问题一般是很容易的。

解决问题的思路除了在解决bug这一方面之外，应对新的需求也是一个能够考察新手和老鸟的点。

通过我的观察，对于新人而言，当来了一个新的需求时，一般都会根据业务逻辑直接上手去做，做到最后会发现有很多bug。但是对于大牛或者老鸟来说，一般会先用一些时间来想一下，看看用什么框架，什么算法来做这个需求比较好，大概需要多少时间，中间可能会遇到什么问题？这些问题应该怎么去规避？当把这些问题都考虑清楚之后，最后在心里或者文档中制定出一个可行的方案，然后再去实施，最后的结果往往是bug很少，代码质量很高。

所以说，解决问题的思路往往能够看出一个人的能力，这对于新手向大牛的方向进军是非常有帮助的一个点。

系统底层的了解程度

对于系统底层的了解程度在很多时候也是区分普通程序员和大牛的区别，尤其是对于一些与底层系统打交道的公司来讲，更是这样。

记得在2015年左右的时候，我去上海的一个团队帮忙带一个比较重要的项目，在这个项目的团队中有一个程序员出身的项目经理能力特别强，并且对于手下的人要求也特别严格。有一天我们技术研讨会，一位技术经理用PPT的方式向我们解释了android端应用程序的数据流是怎么走的，这个时候，那个项目经理问了一个问题：“你帮我把这个数据流在底层与内存的指令寄存器和bus总线的交互画一下，还有就是是怎么调度内存的，这里大概需要多少的开销，内存是怎么寻址的帮忙画一下”。实际上这位项目经理并不是有意刁难技术经理，而是这位项目经理真的是技术太牛了，以至于他对于很多项目中的底层细节都要求了解的清清楚楚，包括怎么和内存交互，怎么去节省开销，怎么去做寻址等等。但是这些，对于一位普通的程序员或者技术经理来讲，确实是非常有难度的，最后，这位技术经理也没有画出来。

还有一次，也是这位项目经理，在开会的时候要求技术人员用标准的UML图来解释内部运行的原理，包括采用时序图和活动图来做。实际上，这些都是我们大学学过的，但是由于大家很少用，所以基本上都淡忘了。这个时候，项目经理说了一句话：“UML是大学时候大家都学过的知识点，在我看来，只要大学学过的，你们都应该是掌握的，不然这个大学岂不是白学？”，确实，这个说法没错，这些都是我们大学所学过的，但是正是因为很多人并不注重这些基础的内容，以及对于底层交互的内容，以至于做了很多年的程序员都没有得到本质上的提升。

所以说，了解系统底层的工作原理，对于一个高端的程序员是非常重要的。

对于疑难问题的钻研程度

对疑难问题的钻研程度实际上可以说是上面几个点的综合体。很多时候，我们会经常遇到一些比较难的问题，这些问题可能需要查阅各种各样的资料、论文，可能需要考虑到各种各样的情况和复杂的环境问题，可能会要求对算法非常熟悉，因此，这个也是普通程序员和大牛程序员之间的核心差异。

我们在这里所说的疑难问题并不是说一个bug，或者是一个小的需求，这里所涉及到的可能还需要有一定的创新能力和综合能力。比如，老板有的时候可能会说这么一句话：“我看最近谷歌出了一个新的技术框架叫XXX，你去研究一下”。这句话实际上看起来是很轻松的一句话，但是这里面却是对一个人非常全方位的考察。

这里说的你去研究一下，我们就要先来定义一下，在企业中所说的研究到底是什么？一般来讲，我们在企业里所说的研究，或者领导让研究一件事，其潜台词基本上就是：“这个东西别人没有搞过，你去搞一下，按照官方文档来搞，可能没有更多的资料，并且，你还要给我出一个demo和一个报告”。是的，这是老板的最终目的，我们可以发现，这个难度实际上是非常大的。

对于一般的新手程序员，往往是按照官网给出的文档搭建出一个demo，然后拿去交差，甚至很多人都无从下手，更或者连demo都搭建不起来。但是对于一个技术大牛来讲，他们的做法往往不仅局限于这些。

之前也跟很多技术大牛交流过这个问题，总结出的结果是，他们会先把这个demo搭建好，然后再去网上找一下与这个框架相关的竞品框架并且也搭建出来一套，并试图改善这两套框架，并用同一套数据分别在这两套框架中进行测试，最后生成一个报告给老板，目的是告诉老板：“这个框架我研究了，并且我还通过类似的框架来证明了这个框架的优缺点，针对于缺点我认为可以用什么方法来代替或改进”，你会看到一套很完整的数据报告。

实际上，很多人都会遇到这样的问题，在2年以前（2018年初）我也遇到过这样的问题，当时领导只有一句话：“你去调研一下目前文本分类在长文本二分类模型下哪个比较好一点”。于是，我整理出了这么一个报告，这个报告里面明确的说明了我都尝试过哪些模型（一共尝试了大概10个模型），每个模型的准确率多少，召回率多少，耗时多久，并和其他厂商的对比是怎么样的，的人，这只是报告里面比较关键的一个部分，并不是报告的全部。我通过这个只是想解释，当时我们做的工作就不仅仅是告诉老板，哪个模型好，你就用吧！而是告诉老板，我把目前主流的文本分类模型都试了一遍，并且用数据做了对比，把平均耗时（工业项目很关注这个）和准确率都列了出来，并给出最终我人分为哪个会好一些的建议。最后老板肯定是非常满意的。

因此，我们说对疑难问题的专研程度指的是什么？实际上，指的就是你对于整个问题的思路、分析，并包括了你的代码能力、 创新能力以及对于行业的敏锐程度。这是一个人能否成为大牛的关键。

实际上，除了上面列举的几个点之外，大牛程序员和普通程序员的区别还有很多，在这里我们就不一一做分析了，也欢迎大家踊跃留言，说说你们的看法。

最后，祝大家以后都成为大牛。