Browsed by
分类:经邦论道

驾着简陋的车,穿着破烂的衣服去开辟山林。

《机器学习(西瓜书)》阅读总结

《机器学习(西瓜书)》阅读总结

因为最近知道经典的《深度学习》中文版译本就要出版了,未来两三个月的计划是重新阅读一遍《深度学习》,中文版的!所以这个月就又把这本《机器学习》的书翻出来重新阅读了。
这本书大概一年之前读过一边,算是目前看到过的,最好的“中文”机器学习“教科书”了。再次阅读,受益良多。
全书结构大致如下:
【1~3章】介绍机器学习基本知识(绪论、模型评估与选择、线性模型)
【4~10章】介绍一些经典而常用的机器学习方法(决策树、神经网络、支持向量机、贝叶斯分类器、集成学习、聚类、降维与度量学习)
【11~16章】介绍一些进阶知识(特征选择与稀疏学习、计算学习理论、半监督学习、概率图模型、规则学习、强化学习)
书在内容上比较全面的介绍机器学习的各个分支,以及重要而常用的方法,它非常合适没有任何背景的初学者看。作者思路清晰,讲得非常清楚,读起来不累。很多内容把来龙去脉讲得很清楚,比只讲做法不讲原因的书强太多。当时看过各种机器学习相关的书籍和文章,总感觉公式太多,晕头转向,直到看过了这本《机器学习(西瓜书)》,才对机器学习有了一次系统性的了解。
作者周志华,是我见识过的第一个把复杂的问题讲得浅显易懂的老师,这本书也算是呕心沥血的作品,诚意满满。个人感觉算是一本适合程序员深入了解机器学习的入门书籍。

Julia 入门

Julia 入门

最近在学习Julia,啃文档 Julia Documentation
Julia 是一个面向科学计算的高性能动态高级程序设计语言。其语法与其他科学计算语言相似。在许多情况下拥有能与编译型语言相媲美的性能。
JUlia 主要用于数值计算,有以下特点:

  • 核心语言非常小。标准库用的是Julia语言本身写的
  • 调用许多其它成熟的高性能基础代码。如线性代数、随机数生成、快速傅里叶变换、字符串处理。
  • 丰富的用于创建或描述对象的类型语法
  • 高性能,接近于静态编译型语言。包括用户自定义类型等
  • 为并行计算和分布式计算而设计
  • 轻量级协程
  • 优雅的可扩展的类型转换/提升
  • 支持Unicode,包括但不限于UTF-8
  • 可直接调用C函数(不需要包装或是借助特殊的API)
  • 有类似shell的进程管理能力
  • 有类似Lisp的宏以及其它元编程工具

目前数据挖掘、机器学习主流的无疑是Python和R。Python生态圈完整,三方的库很齐全,要完成什么功能都已经有很多的实现,直接调用就可以了;R更偏金融邻域,上手快,集成很多数据集。在工作中使用这两种语言进行数据挖掘、机器学习和量化计算肯定是绰绰有余的了。
但正是由于生态发展得太完善了,三方的实现太好了,自己又没有重复造轮子的动力和信心,想了解底层实现的时候,要么是因为代码历史太久远而且结构复杂不容易看懂,要么看着看着就会觉得没有目标而索然无味。这样只会使自己浮于了解API调用的表面,没法深入了解每一个数据挖掘、机器学习和量化计算算法实现背后的原理和思想。
Julia作为一门较新的语言,基础设计的很不错,性能好,速度快,支持分布式和并行计算,还支持元编程,可以说有着成为一门优秀语言的潜质,只是语言年轻,三方实现少才没有很流行。但这正是一个契机,期望能在熟悉Julia语言之后能自己动手实现一些三方库,即避免了重复造轮子,有可以在实践中增强学习。在这个新语言的领域做一个排头兵,作一个探索者会有意思的多。去学习这门语言的时候,查不到更多的资料,只能通过文档和源码来仔细分析,这才是学习程序的真正乐趣,而不是调用一大堆第三方库,却没有一个是自己一行行调试过的。

《程序员的数学3:线性代数》阅读总结

《程序员的数学3:线性代数》阅读总结

大学时代,感觉线性代数是一门比概率统计更没有用的数学课,直到最近逐渐接触图形编程或机器学习等领域才发现线性代数的应用无处不在,特别是在图形领域,全部是线性代数的运算。
这本书主要还是大学《线性代数》的复习,内容包括向量、矩阵、行列式、秩、逆矩阵、线性方程、LU分解、特征值、对角化、Jordan标准型、特征值算法等。回忆一下早已遗忘的内容,当然也会有重新的理解。这些知识点类的书,看完之后依然是没有什么特别的总结,但是阅读过程中发现的一篇文章《程序观点下的线性代数》非常不错,以程序员的角度对线性代数有一个全新的思考,其中“从应用的角度看,线性代数是一种人为设计的领域特定语言(DSL),它建立了一套模型并通过符号系统完成语法和语义的映射”的观点,非常认同的。特别是近期频繁接触numpy,API的风格和线性代数的操作很接近。关于线性代数的思考,这篇文章介绍得很有特点,短期自己的理解有限,受到这篇文章的影响会比较大,也就不重复这些观点了。
但是可以介绍一下这段时间对线性代数基本库使用上的一些总结。计算机发明的出发点是用来计算的(算不算废话?),而线性代数是早就被广泛的应用到科学计算中的,因此线性代数的程序库很早就有了:
BLAS(Basic Linear Algebra Subprograms,基础线性代数程序集)是一个应用程序接口(API)标准,用以规范发布基础线性代数操作的数值库。该程序集最初发布于1979年,在高性能计算领域,BLAS被广泛使用。这玩意儿虽然只是一个标准,但是最早是由Netlib BLAS官方参考实现,用的程序语言为Fortran 77,在那个遥远的年代,所有的计算程序都是由Fortran写的。
CBLAS,时代在进步,慢慢的Fortran做为计算语言,使用的场景越来越少,C语言慢慢占据了统治地位,写C语言的也需要线性代数计算,但是C的语法、环境和Fortran都不一样,好在Fortran和C都算是底层语言,都是编译成机器语言执行的,应此只用将Fortran的BLAS所有API重新用C封装一次就行了,这就是CBLAS,这是针对C语言的接口。
LAPACK:(Linear Algebra PACKage),是以Fortran编程语言写的,用于数值计算的函式集。 BLAS只提供了线性代数的基本运算,最多也就到矩阵乘积,使用上还是不是特别方便,因此需要高层API的封装。LAPACK提供了丰富的工具函式,可用于诸如解多元线性方程式、线性系统方程组的最小平方解、计算特征向量、用于计算矩阵QR分解的Householder转换、以及奇异值分解等问题。
LAPACKE:LAPACKE之于LAPACK,就像CBLAS之于BLAS,提供了C语言的接口
Atlas,OpenBLAS,MKL、ACML、NVBLAS这些都是BLAS的封装,也就是说它们提供了CBLAS(BLAS的C语言接口),但是底层的实现并不是Fortran了,比如MKL可以有针对Intel CPU的汇编级的优化
因为一般LAPACKE底层都是调用BLAS或者CBLAS的,所以LAPACKE就没有太多的重新实现,直接用Netlib的LAPACKE底层调用BLAS的优化实现就可以了。
clBLAS、cuBLAS:这些也是线性代数计算的,但是和BLAS、CBLAS并不兼容,所有的计算都在GPU里面完成
BLIS、eigen:这些都是最近兴起的线性代数算法库,完全放弃了对老的BLAS的兼容,采用全新的自定义的接口

《程序员的数学2:概率统计》阅读总结

《程序员的数学2:概率统计》阅读总结

这本《程序员的数学2:概率统计》有点蹭热点的感觉。首先作者换了,不是结城浩写的了,换成了平冈和幸;其次内容变得没有那么程序员思维了,更多的是偏向概率统计的概念,感觉像一本《概率统计》的书,蹭上了《程序员的数学》这个热门。只是鉴于目前学习和研究的方向确实是机器学习方面,所以还是挑选了这本书阅读以下,复习以下概率统计的知识。
还是简单介绍以下书的内容和知识点,涉及随机变量、贝叶斯公式、离散值和连续值的概率分布、协方差矩阵、多元正态分布、估计与检验理论、伪随机数以及概率论的各类应用。
说实话,读一本类似教材的书确实总结不出啥读后感,跟多的是细节上的体味和知识点的归纳。所以只好借阅读这本说谈谈自己对《概率统计》的理解,之前也提到过,概率统计不算是程序员的基础数学能力,只是针对做机器学习的程序员来说是比较重要的,但也不算是必不可少。自己程序员出身,半路出家做机器学习,对自己的数学基础一直耿耿于怀,虽然能用已有的开源机器学习库完成需求,也能对开源模型做一些简单的算法修改,但是一直觉得自己对概率统计的东西掌握不够扎实,很多东西理解起来很模糊。
后来有一次在知乎上看到一个讨论机器学习专家与统计学家观点上有哪些不同?其中一句话我觉得说的很不错:“统计学家更关心模型的可解释性,而机器学习专家更关心模型的预测能力。”感觉机器学习是一个很工业化的概念,很多流行的方法确实没有太多的数学和统计学上的可解释性,特别是在深度学习领域,大家只知道这么做效果好就一起这么做了。但是很多做机器学习的书籍又喜欢一上来一大段公式,搞得机器学习是一门很严谨的数学学科似的,拔高门槛,让人们对机器学习敬而远之。而其实基于目前的开源实现,机器学习的入门门槛不见得比 Spring 之流高多少。有一些使用经验就能很容易的将业务需求转换成实际产出。只是目前认为制造的门槛太高,现代程序开发分工明确,不是所有写代码的人都需要了解汇编,也不是所有做机器学习的人都需要数学扎实。目前来看,机器学习转换成实际业务产出的条件已经具备,需要的只是如何具体实施的尝试了。
原来看它是一座山,现在看它还是一座山,但能迈过。

《程序员的数学》阅读总结

《程序员的数学》阅读总结

数学学了18年,有时候也不知道数学有什么用。代码写了10年,也觉得用到数学的时候少。只有在最近逐步接触了机器学习和数据挖掘相关的知识,才渐渐明白了数学的重要性。翻出大学的《高等数学》、《线性代数》和《概率统计》,看着满本书的公式和习题,着实需要很大的毅力才能坚持把这些书在看一遍。指导发现了这本《程序员的数学》。这个月看的是第一部,后面还有《程序员的数学2:概率统计》和《程序员的数学3:线性代数》。
这本书面向程序员介绍了编程中常用的数学知识,主要是培养程序员的数学思维。讲解了二进制计数法、逻辑、余数、排列组合、递归、指数爆炸、不可解问题等许多与编程密切相关的数学方法,分析了哥尼斯堡七桥问题、少年高斯求和方法、汉诺塔、斐波那契数列等经典问题和算法。书有着相当不错的易读性和趣味性,虽然讲的都是简单问题,但是讲解的方式和方法还是比较有意思的。
数学不算是编程的基础,但绝对是机器学习和数据挖掘的基础。程序员不需要太多的数学基础。真正需要数学的都是在具体领域里。跟编程结合最紧的,是具体数学,主要是离散数学和组合数学的内容,这一类数学跟程序员的思维密切相关,算跟工作结合比较紧密的。更多的数学则根所在的领域有关:做图形学,以线性代数、几何为基础;而做数据挖掘或者机器学习的,更涉及统计学习理论和最优化的部分。
也许数学对于一个不错的程序员来说,没那么重要,但是要再往上走一步,有一点点技术上的创新,就都是数学的事儿了。有人说过“如果你只想当个Good Programmer,那么数学不重要。但是如果你想当个Great Programmer,那么数学很重要。”
机器学习这个方向,相关资料都大量依赖于线性代数和概率论,以及一点点微积分。所以,如果希望做点有追求的技术工作的话,需要开始花点时间学习数学了。其实万事开头难,如果真的按下心来,看上一个小时,这么坚持个一月,其实就会发现,这没啥难的,就当学门新的编程语言吧。

《七周七并发模型》阅读总结

《七周七并发模型》阅读总结

《七周七并发模型》是介绍并发模型的好书,值得一读。最近是第二遍读这本书了。
很多开发者,对并发模型却只知道多进程和多线程这两种。这本书是全面介绍并发模型的一本非常好的书,介绍了许多非常有用的并发模型:
1. 最基础的线程和锁模型,这个做过Java并发编程的都会有一定的了解。
2. 通过无变量的函数式编程实现并发,是无锁并发的一种模型。函数式编程在一些数值计算的领域有广泛的使用,支持并发应该算是其中很重要的一个特性。
3. 状态和标识的分离,类似数据库里面的事务管理,不过是由编程语言在内存中支持的,可以轻松实现内存事务模型。这本书通过 Clojure 作为示例语言。这种事务模型只在数据库上接触过,也比较熟悉,但是在编程语言层面却是一个新的体验,很有趣
4. Actor 模型是容错性非常高的分布式并发模型,这是 Erlang 的核心概念,在 Java 和 Scala 中也有 Akka 的实现。感觉基本的思想就是将任务分块,分发到每个 Aactor 的 Mailbox 里面由每一个 Actor 自己执行,各自独立完成任务,避免使用同一份数据而产生冲突。
5. CSP 模型是另一种分布式并发模型,很 Actor 模型很像,这个在 Go 里面有 goroutine 的实现。

CSP 通常是同步的,Actor 通常是异步的;CSP 中的 Channel 通常是匿名的, 而 Actor 是有标识的;在 CSP 中,只能通过 Channel 在任务间传递消息, 在Actor中,可以直接从一个 Actor 往另一个 Actor 传输数据;CSP 中消息的交互是同步的,Actor 中支持异步的消息交互。

这是从网上找到的资料,未经过实际使用的体验。
6. GPU 的并行计算主要针对数据密集型计算的并行。将数据划分成很多块,然后由统一的指令执行,Single Instruction Multiple Data (SIMD)。CUDA、OpenCL 这些高性能计算框架都是这么干的。
7. Lambda架构,应该说是目前很多大数据处理系统的指导思想。Lambda架构的主要思想就是将大数据系统构建为多个层次,Batch Layer(存储 Master Dataset,不变的持续增长的数据集并针对这个 Master Dataset 进行预运算)、Serving Layer(对 Master Dataset 随机访问并更新 Master Dataset)、Speed Layer(通过快速、增量的算法对更新到 Serving Layer 带来的高延迟的一种补充,最终 Batch Layer 会覆盖 Speed Layer)
这种非工具技术书阅读带来的收获更多的是思想上的提升和视野的开阔,一段短短的总结实在无法表达太多的东西。粗浅的阅读总结。

《宏观经济学》阅读总结

《宏观经济学》阅读总结

《宏观经济学》版本众多,最近看的是奥利维尔•布兰查德的版本。这是一本教科书,应该算是系统性学习金融知识的一个起点。
之前上学时上课都没有笔记的习惯,阅读一本教科书写一份总结,还真不知道能写一些什么。
社科类畅销书最近也看过一点,之前看得更多的是教材类的书籍。现在又看一本教材,感觉和畅销书最大的一点区别就是“没有观点”。畅销书为了迎合主流读者的口味,贯穿整本书的一般都带有作者的主观观点,并通过不断的例证、阐述佐证自己的观点;而教材主要是罗列知识点和全面的多角度的分析,可以帮助读者系统性的了解并掌握一门知识。
读畅销书或多或少都会收到作者的一些主观意识的引导,而教材一般的分析都比价中正一些。总结一下,以后还是应该以阅读教材为主,畅销书只能作为调节节奏的辅助。
再说说这本教材,只是初读了第一遍。这本书分别分析短期、中期、长期的宏观经济规律,并以此为内容组织的架构。分别分析短期、中期、长期中决定经济总产出水平的因素。
在短期(几年时间)内,经济总产出的变动主要靠需求的拉动,需求的改变可能是消费者信心或者是其它因素的改变,可能导致产出减少,也有可能导致产出增多;在中期(十年时间)内,供给因素,即资本存量,技术水平和劳动力规模决定经济总产出水平;在长期(几十年或者更长)内,教育系统,储蓄率和政府素质决定了经济总产出。这本教材也基本是按照这个思路来组织内容的。
这本教材技术部分主要是IS-LM,AD-AS,索洛模型等几个主要的模型,而这几个模型主要应该注意各种因素对模型的影响。利用这些模型分析财政货币政策的影响应该是学习《宏观经济学》的主要目的。例如货币政策会在短期内影响产出,但在中期和长期内是无效的,更快的货币增长会导致通货膨胀率以同样的速度增长。而财政政策在短期,中期都会对产出有影响。更高的赤字有利于短期内提高产出,但在中期,赤字会降低资本积累进而减少产出。
教材知识点很多,也无法在一篇总结里面一一列举,但是这本教材至少是还需要细读一遍的,这样才能对这些知识点有更深的印象,学习的内容才能比较有系统性。
教材难啃,学习路难,自勉之。

《宇宙的结构》阅读总结

《宇宙的结构》阅读总结

一本烧脑书。
这本书通篇没有物理公式和数学公式,虽说算一本科普物理书,但阅读起来还是挺难懂的。
第一部分主要讲相对论,狭义和广义的。第二部分讲时间的概念,通过熵增加的方向定义时间。第三部分讲宇宙大爆炸理论。第四部分涉及弦轮等新理论。第五部分是讨论时空穿越一些猜想。
自己算是特业余的天文爱好者,从小也对宇宙充满了好奇。一开始以为这是一本科普读物,阅读一下调教心情。结果读起来才知道这本书虽然门槛不高,但要理解其中讲的东西,还是需要努力思考的。
能把一本难懂的书坚持读完(一二三部分细读,四五部分粗读),还是有一些内在原因的:锻炼自己的思维。
目前世面上几乎所有的技术类书籍,形式上都是指导书,很详细的告诉读者要这样做,然后那样做,最后就可以实现什么什么了。但不会详细讲解为什么要这样做。不是说技术类书籍这样的形式不好,其实IT类技术更新快,偏实现,偏工程,这样的形式挺适合工程师阅读的,自己也读了很多这样的技术书,能快速上手工程实现。长期技术积累会让工程师了解很多细节,成为优秀的执行者,但较难成为思考者。
这本书不是技术书,是物理学家写的“科普”书,通过阅读可以体会一下科学家的思考方式。举个栗子:第一部分讲时空观念的时候,先详细讲解牛顿的“绝对空间”(跟着书的思维,我觉得讲得挺对的),然后讲其他物理学家对这一概念的质疑(我觉得也是对的),马赫对时空观念的改进,最后才引入了爱因斯坦的相对论。
其实物理学上的理论没有对错,都是某个时代的物理学家在当时科学实验限制的条件下,通过观察和思考提出的能让规律可解释的观念。大家(物理学家)觉得你提出的理论能很好的解释事物运动或者变化的规律,就会认为你的理论是“对”的。然后随着观察手段的提高,又观察到了其他不符合这一理论的运动或者变化,就需要另外一个天才物理学家通过思考(真的就是思考,实验物理滞后理论物理好多年),想出一个新的理论。
物理理论的完善就是整个人类进步的过程,思考者推动着物理的发展。

《打开量化投资的黑箱》阅读总结

《打开量化投资的黑箱》阅读总结

量化交易对于非技术流或者头疼数学的投资者来说,确实算是一个黑箱。但是如果有一定的数学建模的基础和经验,那么量化投资应该是一个很容易理解的概念。输入数据到量化系统,经过数学模型的计算,最终得到交易策略,其实就是常见的数据分析流程,只是因为涉及到钱,所以关注的人比较多,而这些人里大部分都没有数据经验,所以就显得神秘了。

再具体说说这本书,确实打开了量化投资的黑箱,然后告诉你,黑箱里面还有5个或者更多的小黑箱……

  1. 数据处理
  2. 阿尔法模型
  3. 风险模型
  4. 成本模型
  5. 交易系统

具体可以看看书里面的图。其实量化的核心:模型在每个模块都会有涉及到。书中只是用描述性的语言举例介绍了一些简单的模型,并没有用数学公式进行抽象。考虑到这本书的目标阅读群体,这样的表述是对入门者比较友好的。总体来说这是一本很好的入门书,如果想在量化模型上有更深入的了解,还是需要从金融和数学这样的基础开始的。

这本书目前给我最大的帮助其实就是量化交易系统的划分。上面说的5个模块,就是典型的系统解耦合啊!架构师的最爱👍!之前只知道量化交易系统应该是一个在线系统,但是这个系统如何设计,由于没有一点业务经验,所以也没什么头绪,但是这本书里面的模块划分,让人豁然开朗。每个模块都有独立的功能,可以设计成独立的子系统(微服务),最后在交易系统里融合。当然实施时肯定会遇到各种问题,但是这样模块划分的微服务架构本身不会有太大的问题,方向不会差太远。

书中也描述性的介绍了一些简单的模型,各个模块里的模型都有。入门时可以尝试实现一下这样简单的模型,从数学建模,到代码实现,再到实际数据计算。再慢慢根据实际状况对这些模型进行修正和优化。哈哈,一套量化交易系统就慢慢成型了。技术上无坑,就是钱有风险😄

也谈谈全栈工程师

也谈谈全栈工程师

[转载]也谈谈全栈工程师

今天看到一篇关于全栈工程师的文章,觉得挺不错的,很符合自己的认知,分享一下
原文地址:四火的唠叨


纵使目标再大,人的精力有限,于我来说,早些时候远大目标隐约是“成功的软件工程师”这个样子,但是目标是需要逐渐细化的。这些年我渐渐对自己的定位和未来有了一个清晰一点的认识。确实我有很强的观点,觉得软件工程师需要有足够的全面性,在《我眼中的工程师文化》中我也说“工程师文化,不是只有权力的一面,它对工程师的要求,是每个人都要足够能干,都要做许多的事”……

但是,全面性不代表没有专精、没有方向。深度和广度统一的问题已经有许许多多过往的人和我说过了,不存在一个在某一领域精深的牛人但是知识却很窄,也不存在一个博学大师但是却没有一个自己擅长的领域;而方向更是不可回避的问题,以前和朋友开玩笑总结了几类工程师的发展方向,就像打怪升级一样,有数据库专精、有前端专精、有语言设计专精、有机器学习领域专精,甚至还有企业流程咨询专精、敏捷实践专精的……领域划分实在是太宽阔了,就看技能点数如何分配。

我当然也给自己寻找了方向。在这个网站的右上角我放上了三个关键词,大概是对当前的我一个侧面最粗略的描述:

  • #Web#是我一直以来感兴趣的领域,早有人说互联网软件的技术和发展甩传统软件好几条大街,尤其在见到很多朋友、牛人投身互联网领域,我更对它充满憧憬;
  • #JavaEE#算是我相对熟悉的领域,虽说这几年接触的东西稍微多一些;
  • #全栈工程师#是我的方向之一,粗略地说我现在也已经符合这样的标准,但是仁者见仁智者见智,这是以我的观点而言的,每个人对它有不同的理解,在这里我会说说我的看法。

其他人的理解

关于这个话题,当前颇有争议,虽说大部分工程师表示认可。在Google搜索“Full Stack Developer”的第一条记录,是Laurence Gellert(前汤森路透的工程师)写的一篇名为《What is a Full Stack developer》的文章,这篇文章的观点其实还是非常切合主线的:

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

并且罗列了满足“full stack”应当掌握的各层技术,包括服务器、网络、主机环境,数据建模,业务逻辑,API层/Action层/MVC,界面,用户体验和理解用户、业务所需。

在国内,知乎这个帖子应该算是热帖了,每个人都有自己的看法,比如第一条回复就提到了思维方式和学习能力,但是其中有很多观点偏离了“全栈”这个主线,变成了“我心目中的理想工程师”这样的讨论,就不符合初衷了。

全栈工程师的发展

在系统、全面的大公司,全栈工程师并没有一个稳定的发展职位。我无比赞同知乎那个帖子里面这样的一句话:

一个真正的全栈工程师,目标只有一个:创业。

听起来有些悲凉,但事实就是如此。任何一个方向颇具深度的工程师,都有希望为自己在那个特定的领域赢得自己的一席之地,是权威,也是技艺精深的专家。但是对于所谓的“全栈”而言,很多情况下根本就称不上优势,你会写数门程序语言,会设计API,会写前端代码,会做手机APP,甚至会切图,会和用户沟通,但是倘若在这些方向都难说有哪一项足够强大,那全面性又能在大公司的晋升线路上谋得什么?

但是创业的小公司就完全不是这样了,你不能指望有DBA、技服、产品经理、美工、前端设计师、服务器工程师、操作系统管理员……无数角色,你只能有那么少得可怜的几个人,每个人都必须是全才,搞得定各种事情,经验丰富、视野广阔。出了问题,一个人就可以搞定,而每个人,都可以彼此备份。

这也是“学习能力”在全栈工程师中扮演无比重要角色的原因。毕竟,在全面的工程师,也不可避免地涉足自己不熟悉的领域,快速学习并且把问题搞定,在这样的过程中体现自己的价值。

全栈工程师拥有更广阔的视野和更广泛的学识。全栈工程师可以从更高的角度去看待问题,这比某个领域的专家,更不容易做出错误的决策。

事实上,软件工程本来就是一个复杂的事情,需要工程师掌握和学习的知识很多。在我前一家公司,有这样一个故事,好几年前,公司尝试给软件工程师分档,甚至依此使用不同的雇佣实体:让来自子公司A的最优秀的工程师设计了程序,再让来自子公司B的平庸工程师去实现。最后这个方案彻底失败了,两家子公司的工程师被迫合并,这也证明了,软件工程是一项复杂的脑力劳动,想像流水线工人那样,把整个环境简单地切分成若干个过程,然后通过简单劳动完成,是不可能的。你可以举出很多外包、内包公司中上述的例子,但是在我看来,这只是对劳动力的压榨而已,别指望这样的形式能做出什么伟大的产品来。

“全栈”不等于“全面”

“Full Stack”,这个词其实在英文中使用很普遍,可以直译为所谓“全面的技术栈”(软件工程中,每个领域都拥有相应的数种不同技术,这就是这个领域的技术栈),现在人们加入了自己的理解,但无论如何,它绝不等于“comprehensive”。换言之,一个全栈工程师,绝不等于一个全面的工程师。接触多点领域当然有好处,但是浅尝辄止、仅仅停留在入门级别,那这个领域内,给别人、给项目造成的危害,甚至大过那些一窍不通的人。举例来说,你是愿意去给一坨屎一样的设计和代码修修补补呢,还是愿意干脆重新弄一个呢?当然,也不要走极端,有一些领域的知识,可以透明,那就透明吧,比如,使用云服务的时候,你可以对硬件知之甚少,这对工作并无碍。仅仅为了全栈的名号,追求这样的知识储备并无必要。

“全栈”不等于“全端”

全栈工程师的划分,绝不止以“互联网应用”的维度,更特别地,绝不止以“互联网网站”的维度。微博上很多人说到全栈,就提“全端”,我认为,这实在是莫大的误解,二者是严重不等同的。前端+后端,这只是其中一种粗暴的划分方式而已。就像同事中,有对操作系统熟悉的,有对机器学习熟悉的,把他们粗暴地归结为“后端”工程师,是毫无意义的。即便说到创业,也远远不止互联网领域啊。事实上,要能比较熟悉其中几个领域,就已经是非常难得的人才了。我想不出还有什么其他行业,会像软件行业这样需要不断地扩充自己。

最后,我想用一个无比简单的词来描述全栈工程师,肯定不够准确,但也足够直接——

视野