专栏名称: 聊聊架构
聊聊架构
目录
相关文章推荐
字节跳动技术团队  ·  远程访问代理+内网穿透:火山引擎边缘网关助力 ... ·  21 小时前  
字节跳动技术团队  ·  稀土掘金 x Trae ... ·  21 小时前  
51好读  ›  专栏  ›  聊聊架构

当我们聊技术实力的时候,我们到底在聊什么

聊聊架构  · 公众号  · 架构  · 2018-05-09 10:34

正文

请到「今天看啥」查看全文


有网友说:高斯林来做 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++ 确实能解决问题,但如果我们做的是 android 手机资讯 app,C++ 能解决什么问题呢?自己写个加密库可能比系统带的库漏洞还多,自己用 C++ 写个 SQLite 好像没什么意义。

“架构师才是技术大牛”

架构师几乎是每个程序员的技术梦想,能够成为架构师(真正的架构师,不是 PPT 架构师),技术实力肯定很强,这点是没有争议的,但问题是当不上架构师就不是技术大牛么?我们用原则来分析一下就会发现并不是这样的,架构师并不是全能的,他解决的主要问题是系统的结构设计,还有一些问题是架构师不能解决的,例如 MySQL 5.6 版本通过优化一个 false sharing 问题,性能提升 50%,

(http://www.cis.upenn.edu/~delozier/docs/tmi_micro_2017.pdf)

这种问题点的发现和处理并不比架构设计简单,能发现和解决这个问题的技术人员实力非常高。

以上分析了几个典型的误区,其它的观点,这里只贴一下简单的答案,大家有兴趣也可以套用这个原则去分析一下具体的原因,基本上八九不离十:

“技术高手必须对业务很熟悉” —— 正确







请到「今天看啥」查看全文