前辈之路(4) 2gua兄专访

受访者:2gua

(1) 按照惯例,你先简单介绍下自己的经历吧。

我是学计算机软件专业的。我的计算机编程生涯始于内存只有一、两兆的年代,那时候的学校教育跟市场需求之间的衔接还算是紧密,因为可选项不多,学校的软件工程教育,甚至还可以说引领了市场技术的选择。不像现在,各种编程技术和架构方案多得让人眼花缭乱,光靠学校里的一招半式,远不够你行走江湖。

出道的时候,几乎就是用C/C++处理一切事情,包括数据库表的实现、图像的处理等等。曾经我还参照了当时的WPS(DOS版),用C语言+汇编实现了一个简版的“WPS”。其实,那时候的编程感觉,比现在好多了,虽然IDE是蓝底白字/黄字,严重影响视力,但技术栈单纯,能够让你专注于业务,而不用成天PK各种解决方案。那时还同时用DBase、Foxbase和FoxPro(非视窗版的)开发了不少MIS系统,之后随着Delphi的盛行,MIS方面的开发就逐渐转到了Delphi上。这是我开发生涯的第一个阶段。

随着Web应用的兴起,我的首个Web开发工具自然是ASP,因为那时候的Web应用就几乎被IE垄断了。在一个很偶然的机会,好像是「电脑报」里的一个小版面的介绍,让我认识了PHP 3。虽然那时候我也尝试了一些Perl CGI的开发,但PHP的快速开发与强大函数库的支持,让我对Web开发有了别样感受,因此,之后用PHP做了不少应用。而我对PHP的喜好,也一直延续至今,可以说是一种旧时光留下的美好吧。再以后,J2EE的平台级支撑的优势,则让我开始成为一名Java程序员。可以说,Java开发的角色,是我身上最重要的开发者属性,现在我又常黑Java,真是有一种莫名的矛盾......

之后,我进入了商业智能(BI)、数据仓库(DW)的领域。再往后,逐步转向了管理。现在是南方一家IT公司的部门经理,主要业务方向是移动应用。虽然不像以前那么纯粹从事开发工作,但出于对技术的兴趣和热爱,我始终在不断尝试新的技术趋势。

以上就是我个人发展轨迹的一个概览。

(2)你说自己喜欢函数式风格,那么你个人认为函数式编程相比面向对象编程有哪些特点吸引你?

前面说了,很长一段时间内我是名Java程序员。而正是Java的推动,让OOP风格至今仍是主流。OOP方法是成熟可行的,这一点毋庸置疑。而我也想在这里尽量避免OOP和FP谁好谁坏的无止境争论,因为这是没什么意义的事情。

OOP的开发特点在于,事前的规划设计(OOD)是很重要的环节,因此更多的工具需要依赖:UML、设计模式等等。许多的Java程序员至今仍有一个很大的心理优势,就是认为做Java系统很有一种“正统血统”的味道:拒绝“意大利面条”的代码、懂设计、懂设计模式的运用、懂团队协作开发之道。我曾经遇到过很多的Java程序员,哪怕再简单的任务,都要充分考虑采用什么样的设计模式才能让应用更具可扩展性,这很难说是好事还是坏事。

OOP崇尚“人以群分物以类聚”,以“井井有条”地诠释业务世界的风格。OOP反对者认为:“OO中一旦角色规模膨胀,业务对象之间的关系维系就是一笔极大的开销,横则各种继承、接口实现、组合、聚合等手段,纵则是各种逻辑层次结构,其间穿插着各式各样的状态转换。而函数式编程风格里函数是一等公民,FP关注计算过程与状态的分离、消除副作用、提倡引用透明,使得函数间关系清晰、独立;函数式的数据结构不变性,天然线程安全”。OOP的支持者则认为:“正是现实世界是如此复杂,OOP提供了一种有效手段,将这种复杂关系成功地描绘出来。而FP恰恰缺失了一种宏观描述事物的能力,其从更为微观的函数角度呈现复杂现状就存在局限性”。

其实两者之争仅仅是出于对不同抽象风格的理解及偏好不同而已。现实世界不是非黑即白的关系,像Scala就是两者的结合(Scala的介绍,可参考我给《程序员》杂志的供稿「多面编程语言Scala」http://www.2gua.info/post/48),而像Akka这样的Actor模型库也能同时用于Java和Scala。这其实很能够说明一个问题:OOP、FP都不是问题,都是抽象现实世界的一种手段,各自都有大量的资源支持。争论孰优孰劣是争论不清楚的。事实上,追求完全的OOP或纯粹的FP,都是很困难的事情。

但说到自己的喜欢,那就是个人的事情了,函数式吸引我的地方,不在于其能实现什么而OO不能实现,也就是说,跟哪种范式没太大关系。主要还是因为:函数式语言普遍提供的编程风格让我觉得开发效率更高些,比如高阶函数、Currying、偏函数、模式匹配、惰性求值、Lambda以及丰富的函数工具等等。FP提倡的编程方式之一就是,充分享用各种函数库里的工具!在Scala、Clojure、Haskell里面,你就会充分感受到。只有在万不得已情况下才考虑写宏(比如Clojure)。其实对于动态语言,也有同样的感觉。至于Java,也就到了Java 8才加入了Lambda,现在想想为何老黑Java?可能就是因为它的语法比较老旧吧,而我是比较注重编程舒适度的人。

(3)你翻译过不少书籍,都是和前端联系更紧密一些。但你又不想人觉得你只是前端的大牛,是什么原因?

首先说两点:一,真不敢妄称什么大牛,其实每个人在某个方向做久了,都会有所积累吧。二,也就翻译了三、四本书,不算多。至于为什么翻译的都是前端书籍?这个应该就是纯属巧合了。

其实我们那时候写程序,脑袋里根本没有前端、后台分工的概念,几乎都是按模块划分。你写Java,那好吧,每个人分好几个模块,事前的约定设计好,剩下的SQL语句、存储过程、Hibernate、Servlet/JSP、Spring、EJB、Struts等等等等都是你自己一个人的事儿了,当然包括HTML、CSS和JavaScript。只不过说,现在的前端技术栈越来越“琳琅满目”,也就逐渐细分了角色。我自己的前端知识演进,其实也就是整个前端演进的缩影:从当初做个走马灯而已,到现在什么圆角阴影、响应式设计、Ajax、SVG/Canvas、React/CanJS/Angular。现在的角色细分到这程度,也谈不上是退步还进步。但我觉得,如果市场是这种趋势,必然有其合理性吧。

(4)大部分人有个思维定式:后台比前端更有技术含量,挣的也更多,你怎么看?

首先得承认,后台比前端赚钱,这是一个普遍的现实。

后台比前端更有“技术含量”的思维定式,我觉得有一部分原因是历史旧有认知所造成的。就像我上一点中提到的,以前写前端就像“副业”,写点走马灯啥的。因此,很多人脑袋里的印象就是前端非“主业”。

其次,越是接近业务逻辑的地方,必然也是高层更重视的地方。比如计费系统和营业系统,在批价、结算或销售逻辑上出错时,往往直接影响到收入。问题的发生往往涉及逻辑、缓存、数据库、操作系统和主机等一系列后台环境,环境复杂得多了。

尽管现在的前端复杂度和重要性已远非当年可比,但是我们也可以冷静地思考一下前端的发展趋势。前端技术目前仍处于不够稳定的发展上升期,各种框架或解决方案日日翻新。当你觉得好不容易掌握了一套前端技术栈,却发现其中某个环节又过时了。一方面是热情地研究各种“轮子”而带来了前端的“百花齐放”,另一方面也让自己疲于应对变化。但实际上,如果不太受外界干扰,也只需要选择几个技术组成自己的前端技术栈,应该就可以应对大多数人的大部分任务了。退一步讲,即便掌握了100种工具,也仍会存在不少开发中的坑,这些关键靠经验积累及寻求其他方案来解决了。事实上,我觉得前端社区缺少一个强有力的组织来规划些事情。总之,前端复杂度和重要性的确提升了,但也存在着折腾和泡沫。

综上,这种现象有外因的无奈,也有前端领域自己的原因。

我对前端程序员的建议是,在研究前端到一定程度时,要适度拓展自己的知识面。同时注意不要太过陷入比如JS的什么奇技淫巧当中。

(5)你用过哪些编程语言,一般什么项目选择什么语言来做有没经验分享?

我用过不少编程语言或开发工具,但要清晰地推荐什么情况下选择什么语言是困难的。这也就是为什么一会儿会看到“从Node迁到Go”、一会儿又是“从Go回到Python”的原因。

但在做出技术栈选择时,还是有许多考量点的,比如:

  • 团队的技术储备?擅长什么语言?对新语言的接纳程度?学习能力?
  • 业务/数据类型是怎样的?并发?规模?对计算、I/O的考虑?
  • 语言自身的资源、社区、成熟度?

一般一个团队或组织,经过一段时间的运作,都会有自己的一套相对成熟的技术栈。即使是网站,有些以Node为主要开发工具,有些又是Python或PHP。而且轻易是不会进行大的变化,除非万不得已。毕竟这是伤筋动骨的事情。比如我的团队,在服务器端,首选依然是Java,虽然我老黑Java,但Java已经成为了我们事实上的标配。不可能因为黑它,或不喜欢它的啰哩啰嗦就一言不合换掉Java。特别是现在,要完成一个项目,有n个技术栈可供选择,有时候选择Node还是Python、PHP都是可行的,如果图新潮贸然更迭语言,事后的大坑估计是妥妥地等着你。

当然,现在具备一定规模的项目,靠一种语言或技术解决所有的问题,也不太现实。而且团队也需要保持对新技术的跟进。因此,需要有人进行一些概念性验证(POC)工作。一般我会把研发和开发相对分开,研发方面负责新技术跟进和概念性验证,甚至在一些可作为的内部项目或其他合适项目里使用新语言新技术,在新技术成熟后则视效果推广到开发;开发方面平时则以既有技术栈聚焦于业务项目实现。

安排新技术研究时不能忽略了人的意愿,如果团队对某个课题不太感冒,所谓强扭的瓜不同,最后即使硬着头皮研究下去,效果也不好。这一点我是有感触的。

(6)翻译技术书籍,自己最大的感触和收获是什么?自己选择翻译什么书时候有没什么偏好?

首先,翻译书的感觉是很微妙的。有时候觉得入坑了,再也不想接翻译的事儿了;但是一旦你走上这条路,一段时间不翻译了,你有时候又会冒出来一股想翻译的冲动。总之,翻译是个苦差事,而且没什么可观收入。但翻译真不是为了钱,于我而言,主要还是对技术的热衷驱使我去做这件事情吧。相信绝大多数的译者跟我也是同样的想法。

翻译的感触就是上面这些了。收获?细细想了想,没想出来呀......

翻译必须要挑自己合意的书来翻译,不然已经是苦差事了,又再加了一层苦。

(7)网上有很多人讨论码农要不要从一线城市转移到生活成本更低的二三线城市,你怎么看?

我自己是从小县城出来的,在上海念的书,之后分配到省会城市,期间也跳了两次槽,然后在现有公司一直呆着。其实人总有一颗追求的心,总会对现状有着或多或少的不满。从一线城市转移到生活成本更低的二三线城市,我觉得是“人各有志”的事情,有些人进城,有些人出城。也许有些人是迫于无奈,但终究自己的路得靠自己走。

从技术角度来说,北京的优势无疑是巨大的,国内其他地方无法相比。但人又不可能光靠技术决定一生。也许这是让人神伤的矛盾。

(8)从业以来,有没对自己影响很大的人,能否谈谈为什么是这个人?

我觉得从业以来对我影响最大的人就是我的妻子,我曾在一篇博文里写到:

不得不说,我以前并未发现自己爱阅读,甚至在n年前跟LP谈恋爱时,还被LP说:“你这么年轻,又是学计算机专业的,还成天不读书不学习,怎么跟得上技术的发展呢?”嗯,这句话刺激到了我。

后来,我彻底变成了一个爱读书的人,并维系着持续的技术热情。在我人生中最迷惘的时刻,也是我妻子给予我关键的鼓励和建议。

(9)对在校生有什么学习上的建议。

由于我爱阅读,因此也陆陆续续整理了一些学习和读书的个人感悟:
这些文章里面都提到了我的一些认知。对于在校生,我觉得关键中的关键还是要打好基础,如我在「关于技术的个人选择」中最后提到的:
基本学科是你掌握好技术的根基,比如:算法与数据结构、设计模式、面向对象、数据库原理、C语言等等。基础打牢,才能图精进;基础打牢,才能保持技术及兴 趣的延续性。勿于浮沙之上建高楼。20年前的程序员,跟现在的程序员,都一样辛苦,但快乐是自己找的,不是别人给予你的。技术的厚积薄发,可以让你腾出更 多时间放在其它方面的提升上,比如:项目管理、沟通技巧、个人兴趣以及创业储备等方面;这一点,不论20年前、当下、以后,都是共通的。

当然,每个人的习惯不同,我说的不一定适合所有人。但总之找准自己的路,找准自己的定位就是了。

(10) 请2gua哥自己谈点想说的话题吧。

那我就首先说一下,我黑Java,并不是真的抵触它,哈哈o(* ̄▽ ̄*)o。
因为我喜欢编程语言,那就最后再聊聊编程语言吧。我觉得即使非程序员,也可以接触些编程知识,甚至是VBA Excel编程这样的任务,也能够给你提供莫大方便。对于程序员,看他是否有技术热情,最直白的衡量指标就是看他有没自己喜欢的一门编程语言。而且,最好是工作语言之外还有一门兴趣语言。
Report Story
Tags :

留下你的评论