程序员怎样才算是了解技术细节呢？

写在前面

前一篇文章写了程序员怎样才算是了解业务？后台有人问那程序员怎样算是了解技术了呢？技术过关需要了解技术细节吗？

我觉得这个观点也挺有意思可以讨论讨论。

平时我们也会私下讨论这种问题，比如认为某个高P技术一般啊，看PPT写的大而全，但是好多技术细节都不知道，光知道名词。

比如PPT里面写了在系统设计过程中关注了缓存穿透，但是常见的缓存穿透方案也给不出来几个，或者一讨论到技术细节的时候就对方案本身上产生了模棱两可的态度了，比如不知道布隆过滤器的使用方式。

讨论到服务可用性保障，会说熔断，降级，限流。但是聊到具体降级限流技术细节也含糊其辞，说只会用Hystrix搞。说不明白熔断和降级具体有什么区别。

有人认为“技术人不能丢掉技术”，也有人认为“工作做到上面都是考验人性”，还有人认为“工种不同，技术细节不清楚很正常”。

那技术细节需要了解到多细呢？或者什么算是技术细节？对于一线开发人员，技术专家，架构师，系统负责人，技术总监来说技术细节有哪些呢？

那我就抛砖引玉聊聊我的想法，也许几年后回过来在看我的观点还比较肤浅吧。

需要了解技术细节吗

之前一篇文章写了我认为面试过程中考察面试者应该从技能，知识，方法论几个角度考察，有的东西不懂并不代表面试者水平不行，轻易百度出来的东西也没必要死记硬背。有些东西是需要真实场景来历练的，比如经验。有时要解决有些复杂的问题，没有现成工具可以利用，只能靠自己思考和分析，或者借鉴其它现成工具的原理，就离不开这些看不起的“细节知识”。

所以技术细节在做一线开发时很重要。于是我们如果是应聘或者招聘一个核心骨干一线研发工程师时，热衷于在面试中考察候选人对细节的了解，如果不了解细节，这个人就很浮躁。一路梳理过去，各种细节了如指掌，所有的问题原形毕露，这样工作才称职，自己才放心。

但是随着问题的复杂，职位的升高，了解技术或者说技术细节变成了“不可能的任务”——技术细节太多了，想要对每个细节都了如指掌只会让人疲惫不堪；技术人员也太多了，想要在每个人那里都保持权威也会让人高度紧张。

慢慢发现，这已经不是一个用不用功、专不专心的问题，因为精力有限，要照顾的方面又太多，所以无论你多么用功，多么专心，都会感到力不从心，想找到在技术细节了如指掌，同时技术面较广的面试者也变得越来越困难。

随着负责的系统承受着千万级订单亿级用户量的访问，自认为自己在成长，身边的人也在成长，但是发现没有人可以了解所有的细节。光看职级公司很多“大佬”无所不知、无所不晓，但仔细分析就发现，“大佬”往往只有在自己熟悉或者有充分准备的领域可以谈得很深，遇到自己不熟悉的领域，他们要么不发声，要么用大而全或者不易出错的话掩盖过去了。

所以可以说没有人即了解技术细节，又在多个领域达到权威。

喜欢抓细节，喜欢就细节问题发表自己的看法。不管是在面试还是在平时工作中，多半是营造自己的权威吧。造成的副作用往往是为了考察细节，适得其反，错过了很好的候选人。

如果是中高层管理者，自己的能力模型应该是随时调整的，如果运维弱一点，就要在运维这个点上扎深一点；如果前端弱一点，就得在前端这个点上扎深一点；如果暂时各团队状况都还不错，那就把覆盖面铺更广一点，多为未来做规划……

技术出身的技术领导者的优势是掌握基础知识，对细节的了解，让他们即便面对陌生领域，也能够迅速搭起“从已知到未知”的桥梁，迅速得到“内行人”的视角，迅速和大家找到共同语言。非技术出身的领导者在这方面就要吃力许多，所以也只有少数极高明的人能做得好。

领导的关键就在于“找到合适的人，放到合适的位置上”，只有这样，领导者的钉耙才可以铺得很宽，不必在具体的细节上耗费太多。但是，如何找到合适的人，如何放到合适的位置，这恰恰是需要有足够的细节知识才能作出可靠判断的。

哪些算是技术细节

技术细节的问题，大概可以分为三类：

第一类，号称做过并深度参与的，也着重投入过精力的领域。这样你应该对技术细节了如指掌，说出具体方案之外还需要你对你方案落地过程中遇到的阻碍或者问题进行表达，系统的架构面对一个个问题进行解决才慢慢演进而来的。如果这个领域的细节答不出来，或者经不住追问，那多半是很有问题的。

比如候选人说自己做过服务治理，那么能谈的不应当只是和流行的PPT一样，大而化之地列举服务治理的好处，几个主要组成部分，还应当清楚服务注册流程、服务生命周期定义、异常（尤其是安全）情况处理、扩缩容规范和限制等细节信息。如果谈不出来，“做过服务治理”的经历就应当打个折扣。

第二类，是在任何系统都需要使用的一些技术点，比如我们都用java，jvm，多线程，各自锁，并发编程相关，mysql原理及架构，高可用，高并发，高性能系统的常用体系和解决方案还是需要知道的，系统要做复杂一点，在分析和设计的时候，这些知识是不能空缺的。

比如光在真空中的传输速度是30万公里/秒，而在光纤中的传输速度是20万公里/秒。这样分析技术问题时才有根据，比如北京到上海的直线距离大概是1200公里，所以单程理论传输时间大约要10ms，则ping值在25-30ms左右是正常的，没有更多优化空间优化。但南京到上海的距离只有不到300公里，如果ping值也在30ms，则网络上估计还有些问题。这样的细节知识，就是前端、后端、运维都可以用上的（此处数据经过老高(高春辉)确认）。

第三类，是候选人没有专门做过，但也不那么基础的细节。这类细节如果答不上来，其实并不是很要紧。主要是考察候选人是否可以就之前积累的知识或者方法论进行横向迁移的学习能力，侧面考察了技术的扎实程度。

后记

参考余老师的观点：

技术领导者的精力是有限的，能力模型既不应当是“博而不精”的宽泛，也不应当是“深而不广”的专注，甚至业界流行的“T型人才”也不准确。对技术领导者来说，最合适的能力模型应当是钉耙型。

钉耙很宽，扫出去可以覆盖一个面；同时钉耙又有许多齿，可以在某些具体的点上深入。不过无论如何，太上老君只有那么多神镔铁可以用来打造九齿钉耙，在资源有限的情况下就得具体分析，考虑钉耙到底有多宽，有几个齿，每个齿应该有多深。

技术领导者，最重要的是保持对技术的敬畏，以及不排斥谈细节的意愿，所以虚浮的作风是万万要不得的。但同时，也不必苛求自己时刻了解所有细节。

技术人要有足够的技术素质，在宽度上能覆盖这些领域，能找到靠谱的人、评估出靠谱的方案，或者在深度上能保持（经过一段时间的学习了解）介入能力，这些问题是多半都是可以解决的。

转载于:https://my.oschina.net/u/1000241/blog/3070508