汝果欲学诗，功夫在诗外——谈工程师的自我修养

笔者按：余加入研发部已近两月，对整个部门有了初步的了解，亦从细小之处窥得公司全豹一二。个人在工程管理、团队建设、部门协作方面都有些感悟，当然最想谈谈的是研发人员如何提高自己的单兵作战能力。鄙司公众号是一个内部交流暨对外展示的平台，市场部诸位同仁在此笔耕不辍、竞相弄潮，兄弟也来写篇下水，发点研发部门的声音。斯是新年，落下点感悟，若是能共鸣于诸，看到新年有新气象，那便是功德一件了。

香菱学诗是《红楼梦》中一段精妙的插曲，香菱对黛玉说：“我只爱陆放翁的诗，‘重帘不卷留香久，古砚微凹聚墨多’，说的真有趣！”。黛玉听后说道：“断不可学这样的诗。你们因不知诗，所以见了这浅近的就爱，一入了这个格局，再学不出来的。你只听我说，你若真心要学，我这里有《王摩诘全集》，你且把他的五言律读一百首，细心揣摩透熟了，然后再读一二百首老杜的七言律，次再李青莲的七言绝句读一二百首。肚子里先有了这三个人作了底子，然后再把陶、应、谢、阮、庾、鲍等人的一看。你又是一个极聪敏伶俐的人，不用一年的工夫，不愁不是诗翁了！”

黛玉之言，翻译成咱们能理解的白话，就是说：若是想成为一只攻城狮中的战斗机，不能仅仅囿于你会的某种计算机语言、某个熟悉的框架，而是需要先去习作基本的算法和数据结构，再去了解操作系统原理，再去学习计算机网络，肚子里面有了基本的数据结构的底子，明晓了操作系统的基本知识，再对网络协议有了大体的认识，再去学一门C++/JAVA等编译型语言，继而再去掌握一门动态语言如python/perl，再去你感兴趣的领域里面去探索，例如做前端的去研究研究angular/react等，做后台的去探索nginx/redis/mysql等，搞数据平台得学学spark/storm/kafka等一系列工具，待到你踩了不少坑、修了不少bug、解决了许多在工程中遇到的实际问题之后，就会对计算机科学有一些自己的感悟，就可以体味到独上高楼，望尽天涯路了。

黛玉的话，寥寥数语，把诗歌那点事儿，都给解透了。但是要学好了，实在是不易，就如这些年在北京城街头的房地产中介，立块牌子上书某某小区37平，只需350。那初上城的陈焕生，不晓得写的是何意，凑近一瞥，原来350这数字的尾巴上，还有一个小小的“万”字，简直是可以让人“垂死病中惊坐起”。的确，要参透王维佛偈、工部句法、太白气象，再从陶潜清静无为一直习到清新如庾信、俊逸似鲍照，是一个长期提高的过程。但凡事鲜有一蹴而就则可成的，一蹴而就那是国足后卫在踢球，一个大脚开到前场，余下的则不关本道爷清净。斯是说笑，但若是反躬自省，恐怕中枪者不在少数。工程师不能只管“做完”手上被布置的那点任务，就不再去多用功夫了。请注意这里的用词，仅仅是“做完”，而不是“做好”。例如，有一批功能差不多的作业，“做完”就是不断把以前做的代码拷贝到当前的任务中，而“做好”则是把与业务无关的部分，总结提炼出来，写成公共函数，作成自己的库，更进一步可以辅之以“元编程”的技法，写一个小工具，自动生成代码。这样就可以避免做大量的重复劳动，在无尽的加班中燃尽青春的红烛。再者，在提炼、抽象、整合的过程中，个人能力也会得到质的提高。而若是图一时方便，大量去拷贝代码呢？只会给你带来无尽的bug，让你陷入到加班的死循环之中，最终的结果是，天天办事事不尽，月月加班加不完，看似你很努力，其实只是在修改bug的过程中，制造更多的bug！

上文仅仅是说的一个场景，其实兄弟发现我身边有很多无效却又不得不加的加班存在，究其原因，就如黛玉所言：“断不可学这样的诗。你们因不知诗，所以见了这浅近的就爱，一入了这个格局，再学不出来的”。如果不跳出现有的眼界，任你写再多的诗，也是徒费纸墨，见笑于茶歇酒座之间，例如民国军阀张宗昌（一说为韩复渠）就酷爱作诗，此列其代表作《咏泰山》供卿赏析：“远看泰山黑乎乎，上头细来下头粗。有朝一日倒过来，下头细来上头粗”。诸君莫笑，请自省之，自己是否也在天天创作这类“黑乎乎”的项目呢？

见贤思齐焉，见不贤而内自省也。我们笑过“黑乎乎”，则该想想自己如何跳出“工作效率低、工程质量低、个人能力低”的“三低”困境。一言以蔽之，就是“汝果欲学诗，功夫在诗外”。除了耕好自己的那一亩三分地，还得去了解一下整个业务逻辑流程，是为所谓的“大局观”。有人不解，我若是了解了业务逻辑流程，要产品经理何用？然而事实是，大多数时候，你根本遇不到一个非常好的产品经理。当然关于产品经理的话题，@北冥乘海生这篇《产品狗的圣战》中已经讲得相当清楚了，于此不再赘言。另外，排除掉产品经理的因素，作为一个合格的工程师，你也应该知道自己在干啥，友军在干啥，对自己主攻的方向做到一个专字，对相关的方向做到一个博字，例如做前端的需要大致懂得后端有些什么逻辑，做后端的需要知悉日志中的各项参数对算法大致有些什么影响，从产品、技术、整个项目的角度去思考问题，才能做到不过度设计、不遗漏逻辑、哪些优先级高、哪些部分是瓶颈。

了解业务逻辑，熟悉自己所做的产品，这是从宏观的角度去解读“功夫在诗外”；而从微观的角度谈，一名优秀的工程师需要去了解自己项目中所使用到的各项技术。“纸上得来终觉浅，绝知此事要躬行”，我们现在大量的使用开源软件、开源框架，如果对自己用到的技术不了解，仅仅满足于“会用”，那么不出问题则已，一出问题就只有“以手抚膺坐长叹”了。前些日子面试了一个号称搞大数据的人，此人侃侃而谈，教育我说，不要用mysql，要用oracle数据库，大有煮酒论英雄之势。问其原因，却憋不出个所以然来。又谈spark某个版本不好，复问其原因，该生说因为他写的某个job在这个版本上跑不过，换成新版本就可以跑通了。这类“人才”就很让人放心不下，属于“用打油诗冒充格律诗”一派，这也反映出当下受资本热钱追逐的互联网行业弥漫着的一股浮躁之风。其实静下心来读读优秀的开源项目是十分有裨益的，从自顶向下的角度，可以看到优秀软件的设计思路，去学习大师如何去抽象、解耦；从自底向上的角度，可以去学习到具体的优化，甚至能细化到每一个系统调用，相当于把操作系统原理学习整理了一遍。如果有了这个实践“躬行”的过程，日积月累，可分云泥。

阅读好的开源软件代码、高质量的技术书籍，是提高个人能力的捷径。可惜的是，我所了解的许多同学，仅仅是满足于做完工作任务、加班做完工作任务、去网上搜代码并且不求甚解地复制粘贴。较之于用提高工作效率的方式，更喜欢用蛮力去制造一堆看似没有bug的代码，而谈到花点时间去做些研究性的工作，却是以工作忙为挡箭牌。对于这一点，我深不以为然，项目是永远做不完的，工作也是永远做不完的，每天抽出两个小时的工作时间，用于系统地阅读分析优秀的源码和优质的技术博客，逐步积累技术，于公于私，都是有百益而无一害。

再者，为团队做技术分享，亦是提高自我修养的妙法。整理资料、开坛论道，就需要去考虑所讲的每个细节有无纰漏，在这个过程中，自己必然会促使自己去进一步理解认知，这就是所谓“温故而知新”的过程。这一点，更是见诸于有成功经验的过来人：阿里内部就有规定，升任高级技术职位，必须有一定的团队分享经历。

“为人性僻耽佳句，语不惊人死不休”，这是杜子美对自己遣词造句的要求，也可作为工程师给自己的警句。理解商业产品逻辑，钻研几个优秀软件，做有深度有干货的技术分享，确实，这些都很难，但成为一名优秀的工程师本来就不是简单的事。