怎么评价有些人喜欢研究各种源码和底层知识，但是他实际解决公司系统问题的能力不行？

你得看这种研究是真研究还是假研究。

比如你说学习编译原理，看完有动手写相关代码吗。

知道词法分析怎么实现吗，语法分析呢？

如果都不会，这种情况我称之为没学过，即假研究。但有些人会觉得他研究过（看==研究）。

这种情况也不少见，身边就有大把现成的例子，题主，你应该懂了吧。

因为解决公司实际问题需要很多的因素：

对公司系统和代码的熟悉程度， 对公司工程开发流程和方法的熟悉程度， 对公司要解决问题领域和算法的理解， 和团队内外的协调沟通能力， 和领导的关系和协调等等。

这些因素虽然很多是软性因素， 但对工程师完成项目非常重要。

而个人研究技术没有这些因素， 可以由个人的兴趣和能力来掌控。

我以前的团队中有一位阿拉伯国家的topcoder 编程优秀选手，涮题编程大赛的牛人，然而工作成绩平平， 感觉就是和团队沟通能力不够。

1. 不需要知道底层，就能解决问题，且质量和效率也挺好。
2. 不知道底层，也能解决问题；但知道的越多，解决问题的质量和效率越高。
3. 不知道底层，无法解决问题；需要对底层了解到一定程度，才能达到目的。
4. 就算知道了底层，也解决不了问题；换言之，解决方案此路不通，需要换方向；了解底层，可以更好的找到新的解决方案。
5. 无论底层知道多少，问题本身无解。

以上，无论哪种情况，了解底层除了占用精力之外，大体有益无害。

另一边，框架或接口的设计者，很难达到第 1 种设计效果（比如，java 开发的公共库大多提供了源码，还有文档，也是便于使用者解决问题），更何况公司内部封装的，风险更大。

解决问题靠的是经验，工具和方法。

而研究源码收获到的是知识。

知识能不能变现成经验，工具和方法都是看个人造化以及启蒙老师的。

这个时候就不得不提公司里的两类大牛了，一类是知识型的，一种是工程型的。

工程型的我们见的最多，他们主要厉害在给所有见到过的问题给出解决方案和见解，或者给不出解决方案的时候给出缘由。他们存在的价值是工程项目的中流砥柱，保证项目的正常运行，或者拔高项目的上限。

而知识型大牛并不能很好的成为工程人才，他们可能是科研人员，也可能是某些核心技术部门，目的是优化现有的工具，框架或者发明新的。他们的产出不是某个业务的解决方案，而是去优化原来的解决方案，或者引入新的技术。比如游戏行业里的技术美术更像这样一类人，美术渲染出bug了，他们不一定会修，但是他们可能会把新的渲染技术不断的带到项目中来，他们往往是为公司整体服务而不是专门为某个项目服务。

因为他看的不是公司的源码和底层知识。你看了这个库不代表你不看那个库就可以给那个库修bug。这基本上不可移植。

很多面试官面试时喜欢问各种源码和底层知识。

所以一个程序员如果解决需求的能力很厉害，但是底层知识不行，面试时容易挂。

最近我们组有些人内推面试挂了，就是因为底层知识不行。。。

工程师在屎山上搬屎的能力并不比专业的熟练的屎山工人强。而屎山工人当然会认为工程师的物理知识和工程技术是好高骛远。当然也有屎山工人认为「学好数理化，啥屎都能挖」

谈一下自己的看法。

我认为学习基础原理和解决实际问题之间是相辅相成的关系，而不是因果关系。你很难讲我学习了某部分底层知识，就一定会解决哪些问题。这个有点像上大学和人生赢家的关系。你能说上了大就一定会成为人生赢家吗？现在肯定是不能的。但上大学对你成为人生赢肯定是有帮助的。

不论你出于什么目的学习底层知识，学到了，对你解决实际问题肯定是有帮助的，这个毫无疑问。同样的，你遇到的实际问题，又会驱使用你主动学习底层知识。所以，这是一种相辅相成的关系。

解决实际问题最关键的是什么？是你有多么深的知识储备吗？其实不是。解决实际问题的关键其实很简单，就是发现问题。只有当你发现了问题，你才有可能着手去解决它。至于你是单枪匹马自己研究还是寻医问药求助他人都只是执行层面的事情。不能发现问题，一切都无从谈起。

那如何发现问题呢？方法有二。其一就是监控。我是做后端开发的，监控和日志是线上运行的重中之重。说白了就是要尽可能的掌握统统的运行状态。这也是我们要在自己的轻量级业务框架 sniper 内置 prometheus 和 opentracing 支持的原因，关于 sniper 框架大家可以阅读我的这篇文章

通过监控发现问题靠得是工程化思维，靠得是经验。这种方法只能用于事后及时止损。如果相要预防，那就得靠第二种方法，学习基础原理了。

想必大家都用过数据库。如果一张数据量很大的表没加索引，查询一定很慢。我们学习基础原理就是一个建索引的过程。把知识索引到大脑，当遇到相关的问题的时候我们才可能会注意。就如我之前讲的一篇文章

如果不去学习基础原理，你就不会注意到 protobuf 字段编号大于 16 的时候会占用两个字节。但学习的过程是一个缓慢的过程。所谓「书到用时方恨少」。学习的过程一般不有那么强的目的性，也就很难有立杆见影的效果。

所以说，解决实际问题和学习基础原理是相辅相成的；一个是经验性的，一个是理论性的；一个短期的，一个是长期的。不能将二都割裂开来，也不能偏废。两手都要抓，两手都要硬。

不是说「读一本好书，就是和许多高尚的人谈话」吗？读源码学原理也是在和计算机行业的大拿谈话，本身也是一种享受。

很多知识我认为是屠龙之术，90%的日常场景用不上，10%的场景，你不会这些知识就不太可能能解决/需要花成倍的时间去解决。90%的场景更多依赖工程经验和对本身业务线上的代码和架构的熟悉程度。

计算机有4种人，一是动手很强，但是理论不行。这种踩坑就不懂，经常查来查去。

一种是理论很好，但操作不行。这种就纸上谈兵，但经常能唬住人，虽然代码能力不好，长久下来会成长很快，如果不是，炒了吧，谁要这样的扯大炮的。

一种是都不行，萌新或者不明所以。

一种是都可以，那是大佬。

鲁迅有一段关于读红楼梦的论述，那么：

读红楼梦，能不能解决兵法问题？

读红楼梦，不同视角的人，收获不一样，能解决的问题也不一样。

还有，读得质量不够，能不能记得住也是个问题。

就算全部记住了，数学考试公式全记住有用么？最终还需要应变能力，需要不断实践。

怎么评价？ 爱研究总是好的，不管他的目的是什么，方法有没有用到点上。

研发和架构的能力要求不一样。

研发强不一定架构强，做架构提炼问题比解决问题重要，毕竟很多问题用第三方工具也能解决。

但研发水平会制约架构落地的手段，甚至目标的达成。毕竟哪怕用第三方工具，瓶颈也就在这些工具上了。

基本上是木桶上的两块板子。

最后，理解他人工作的价值最重要。

其实好多时候解决问题真的靠运气，我也有时候被一些问题连卡个把月，在早期，甚至卡好几个月，卡半年，你能说我蠢吗？我还喜欢挖新坑，去一些完全不懂的地方慢慢想透，不一直呆在我搞了十几年的东西。我不喜欢看代码，因为太消耗耐性，尽管bat都爱吹逼有码神，我还没见过比我牛一倍的人呢。而好的研发环境，需要各种人，有的人夸夸其谈，引经据典，有的人啥也不会闹个傻样逗得大家开心，有的人善于交际什么时候都能挖来情报，技术领域情报也重要的不行，有的人善于卡死线，有的人永远是蜗牛速度但是没有他推不倒的问题。有的人喜欢研究新问题，对于已知问题没兴趣，有的人就喜欢用大学四年的知识玩一辈子，除非世界爆炸行业不见了，他并不想捕获新知识，有的人能从一堆屎一样的代码里发现蛛丝马迹，有的人不爱处理麻烦事能把复杂的事变简单，有的人啥都能学会但是做项目完蛋。码农社会并不是简单的搬砖锻炼身体式的简单组织，一个容量够大的公司，有野心的企业，需要一个社会式的人员组织结构，除非全是无脑生产。大家谁不明白，你在公司呆很久，自然知道这里的一草一木，一花一露，所以量化码农的工作是非常困难的，我倾向认为不可量化，我经历过各种KPI，KBI，OKR，可以这么说，hr是it公司最神学的部门，一个公司的人事制度今天生于斯，明天就可能死于斯，公司业务好的时候随便吹，不好的时候大家都觉得别人是猪队友，人之常情。

在我有人事裁量权的地儿，我愿意多样化研发团队，我不是怕别人取我代之分而治之，而是深知多样性的意义。我是医学院出身，对我来说，我读书时学的那些东西，统统没个啥用在我后面职业生涯里。对我最有用的就是精神病学，我看过好多paper，大家都知道我经常黑做心理的，做精神的，黑归黑，但是我那时候神经外科，学校把所有做神经有关的，解剖的，组织胚胎发育的，精神病院的，生理的，甚至电子工程的，甚至心理的，遗传的，赶到一起，有的人擅长动手，有的人善于最别人的工作，有的人善于批评，论证别人是错的，有的人善于发现新问题。尽管我读书也没做出啥让人记住我的工作，但是这种多样化的人给他们一起凑深深影响了我的研发思路。精神病的核心要义是所有的精神疾病几乎都是人类作为一个社会进化群体整体获取生存机会的表现，而现代社会可能错误把他配置在不合适的地方。精神疾病本身也是脑的核心功能点可能。我看过无数做snp的paper,看过无数小鼠果蝇斑马鱼的行为实验，可能这些数据加在一起，就是人类社会，也是个研发族群。

而中国，尤其某些暴发户的大厂，因为没被打过脸，往往执行更加功利导向的kpi,诸如阿里这样。有那么一句，只有偏执狂才能生存，很长一段，尤其在行业快速增长期，放个屁都好香，说什么都是对的，反正业务在火速增长，但是一个产业一旦进入瓶颈期或者成熟期，就需要各种精神病互相组合磨合的队伍，这就是中国的it团队和微软，18摸，英特尔，ti这种50年以上的老店的根本区别，容纳无用的废物，接纳夸夸其谈，容纳很多不同的人的深度。那种脱了裤子裸奔全靠不要脸取胜和精心策划，多样性的文化，智力发育的队伍，其能够守住地盘的稳定性，差距很大。

说白了，你不是码农，永远铲屎锄地，你的朋友里有人抬头看天，有人钻地几万米去做一件事，有人乐于分享新东西，有人善于善于猜测，有人愿意把东西一点点补起来，都是好事，揭别人的短容易，真的组织一个有生机配置合理的研发团队很难。如果你有幸是个头儿，你做的最多的事可能就是忍，忍这些精神病和你不一样，忍过他们毫无产出的岁月，忍他们的极端行为，找到一个人的闪光点把他合适的权力和资源配置给它，而你总是抱怨你的人不行，说句放肆的话，马云任正非那一套，在以90后00后为研发主力的今天，统统没啥用了。这些老家伙会自己变，而新的一代人，也得变。

说白了，文人相轻，大家都想夸大自己的贡献，但是你得忍住洞察下别人。

你有计算机本科甚至博士学位，修电脑还不是被华强北的小工秒杀？

正经回答，现实我见过的这种人，一般分两类：

1. 真的是动手能力差，适合做研究，不适合搞工程
2. 夸夸其谈之辈，嘴炮王，好表现，只不过是你在干活的时间，他用去看文章了。真的多问点，会发现也没有这么懂。

第二种人更多，要知道，你真吃透了技术原理，一般动手能力也不会太差的。

我以前确实有类似的毛病，现在在一点点改正。

不过题主的描述逻辑可能有些问题，

首先，喜欢研究 ≠ 全部研究清楚

一个人真的能把各种源码和底层原理研究清楚了，那么他已经比很多人都优秀了。但是，如果一个人只是"喜欢"研究，并不能说明他都理解和深入，毕竟技术圈有很多过度包装甚至吹嘘的人，学术圈也有很多类似民科的人。

其次，我觉得几乎不存在那种代码分析的很清楚但是啥问题都解决不了的人。

要么是他不愿意解决，要么是没给足够的时间锻炼。对于前者，我没啥说的。对于后者，其实很多成绩优秀的应届生或者刚工作不久的人都是这样的，他们会学习会看代码，会查资料，但是动起手来不太行，因为缺少项目锻炼。合理的给他们安排任务，时间长了问题就解决了。

我觉得看源码并不是一个很简单的事情，写代码也不是一个很难的事情。

经过多年实践验证和修改的好代码是非常有价值的，其中蕴含的知识和经验也是非常丰富的，想要完全理解并非易事，需要有良好的基础、良好逻辑分析能力与学习能力。

如果你很能写代码，也不要瞧不起那些学术能力很强动手能力较差的同学，人家也只是锻炼的不够，拿个项目好好锻炼一下，可能不比你差。

最后，程序员有很多，每个人都有自己的优势，能看懂并源码并梳理出原理也是一种能力，能够很快将思路用代码实现更是一种能力。大学的很多老师他们可能很多年都不写代码，但是并不影响其做学术。同理，程序员中也可以有一些人擅长底层架构学习与设计，而不擅长解决各种具体的bug，只要有这种需求的位置，那么他的存在也就是合理的。

如果，你能做到既擅长研究与深入各个源码框架，又能很快的实现并解决各种问题，那当然最好。最怕的就是你这个人水平和能力都不行，天天用看了什么牛逼的代码的方式秀优越，没救了。

不了解业务的架构解决的是通用型问题，了解业务的架构解决的是实际公司系统问题的人。

两种人都需要，因为有时候太了解业务，太知道业务的人做不好合理的未来型架构。有时候不了解业务的人所谓旁观者清更能指出未来可能发生的问题。

我个人的理解如果没有实实在在地写过5年以上业务的工程师，是根本没资格做整体项目架构的（帮架构师完成架构设计不需要）。

如何评价那些眼高手低的人，不需要在这里回答，所有眼高手低的人大家都讨厌，题主摆明了来喷的。我只是说出了另一种可能。

一个开发项目确实有时候需要有不同的声音，读源码没什么不好，就像写业务一样，都是工作而已，没有高低。

他们中的大多数只是在准备面试。或者说，职业规划？

个人之前在国内一线大厂，后来跑到海外，综合经历来说，其实这是中国技术圈一个非常奇葩的现象。个人认为和国内的招聘，面试方式有非常大的关系。

我个人经历来看，在国外面试，上来就是在一个网页上写代码。啥？你是架构师？那咱们 写更复杂一些的代码。武林高手往那一站内行就能看出来不同，面试随便写三五个类就能看出来编程功底。相反那些中间件和工具的实现原理，反而很多人都不知道。事实上工具就是拿来用的，所谓底层知识中的一大半对日常工作并不会有太大帮助。真正需要的时候，看一篇文章结合编码功底，很容易就能理解甚至实现一个差不多的东西。编码是很难速成的，看够多代码，写够多代码，编码和解决实际问题的能力自然不会差。什么面向对象设计，函数式编程，怎么把代码写的好维护好扩展好测试（包括很容易被单元测试）好排查问题，是个日积月累的“内功”。内功在那里，什么招式看着图就能使出来。

而国内面试，主要是比吹牛。当然这个牛吹起来逻辑上得成立，所以在技术理论上不能有漏洞。大多数人天天在研究那些理论技术，为的十有八九其实是面试的时候吹牛理论上能通过，然后混个足够高的岗位，也就不需要真的去编码解决什么实际问题了。

相比编码来说，大多数“很牛逼”的理论知识实际上看完一篇博文就能吹的大家一愣一愣的。相比日积月累的编码能力，这是一种“速成”技能。在我观察来说，绝大多数“架构师”岗位面试，如果面试官不看真实履历的话，只要准备好需要看的文章列表，对计算机本科刚毕业成绩过关的新人来说，一周内能速成。

当然，现在的面试官有时候干脆也不要人家吹牛了，干脆问一些理论知识。能不能用代码实现？面试官也不能，他不会问你的。其结果就是内功不到位，招式说起来一套一套的，从降龙十八掌到九阴真经无所不通，然而真上阵却连罗汉拳都打不出来。

面试时当场编码，也只应用于刚毕业的学生。大家甚至觉得架构师不会写代码是正常的。这绝对是中国这个行业独有的扯淡理论。放眼世界技术领域，你看到哪个行业大神写的代码不漂亮了？这不跟乔丹不会运球一样？

以前在国内某大厂的时候，同组里有个mysql专家，什么锁机制隔离机制索引，能讲得所有人大呼牛逼。其实有时候我就特别想问，你随便写一个出来看看？我很清楚他写不出来，他随便写点复杂度低得多的业务代码写得稀烂。这会已经是“技术专家”了，去小厂能做总监。天天画一堆框框的ppt，看上去巨牛逼，我只知道实现出来八成一塌糊涂。

技术圈ppt架构师大行其道，再加上“年轻饭”“996”，实际上国内真正编码能力很强的技术人员非常非常少，大多数到能接近练成的年龄都被迫转型了，或是被一群职位巨高实则编程菜鸟恶心得不行。编码强悍在应聘过程中也毫无优势，面试官也不会觉得那是什么要紧事，因为大概率他自己也不行。

这是国内行业需要反思的问题。也是保持互联网技术暂时领先能持续下去的重要条件。但实际执行却非常难，那个老板敢开掉所有的ppt架构师？回过头来，真正的技术人又少之又少，满足不了市场需求了。

还有各种说什么架构师不需要写代码强的，架构师岗位的职责是什么？减少开发成本，控制软件质量是其中一大部分吧？你编码不过关怎么评估一个复杂设计的开发成本？怎么评估开发难度？对开发难度无法准确评估，又怎么知道你的团队能不能高质量实现？就像写一个内存索引，对我来说是基本功，对很多架构师来说呢？代码的维护成本又差多少？

噢，估计不小心会断很多人财路。引用一句话：当然我在扯谈。

说明你这个环境没能吸引到基础扎实的同时工作能力也强的人，你应该反省一下为什么自己在这种地方

实际问题很可能是：

小明做了个A，小刚在A里加了个B，小芳把B修改成了B'并且为了兼容C，小强直接把A修改成了A'，并且为了保持B不变的前提下，把C变成了C'并且加上了D、E、F、G，而小亮发现了B'和E、F之间出现了问题，于是把E和F分别用X和Y替换掉，并且把B加了个接口Z。

那么问题来了：你解决上面这一套逻辑，对你的人生有帮助吗？不，没有，以上的所有东西都是屎，你所做的只是对屎山进行受力分析，并且在恰当的位置上再拉一泡屎，为了保持屎山的稳定性和兼容性而已。

那么你做这些是为了什么呢？是为了老板，老板要把生意做下去，但是屎山已经没办法铲掉重盖了，因此你不得不充当“屎山守护神”——为的是了解屎山的过去复杂反人类的设计从而维护老板“屎山”的稳定性。

归根到底，你解决的是“老板做生意用的屎山要塌了”的问题，你维护住的是老板的生意，你吃的是前人留下来的无数的屎——但是吃屎这件事儿，对你的人生没有帮助，你感到没有兴趣甚至无比恶心反胃。

但是人总是要有品味和信仰的。去研究自己喜欢的东西，既是享受，也是未来脱离屎山的准备。

因为他天天写部门的辣鸡业务代码，没学到啥。有多余时间你还不让人家研究些其他东西？

要我说，如果你自己写的代码值得人家研究，或者有人教，人家也不至于天天研究源码…