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

写在前面

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

我以为这个观点也挺有意思能够讨论讨论。

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

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

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

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

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

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

须要了解技术细节吗

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

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

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

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

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

因此能够说没有人即了解技术细节，又在多个领域达到权威。

喜欢抓细节，喜欢就细节问题发表本身的见解。不论是在面试仍是在平时工做中，多半是营造本身的权威吧。形成的反作用每每是为了考察细节，拔苗助长，错过了很好的候选人。

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

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

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

哪些算是技术细节

技术细节的问题，大概能够分为三类：

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

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

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

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

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

后记

参考余老师的观点：

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

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

技术领导者，最重要的是保持对技术的敬畏，以及不排斥谈细节的意愿，因此虚浮的做风是万万要不得的。但同时，也没必要苛求本身时刻了解全部细节。

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