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

　　近日喜获珍岛研发部供稿一篇，作者独具匠心地从“香菱学诗”切入探讨了研发部人员如何提高单兵作战能力，字字珠玑，值得赏阅~

　　笔者按：

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

　　香菱学诗是《红楼梦》中一段精妙的插曲

　　香菱对黛玉说：

　　“我只爱陆放翁的诗，’

　　重帘不卷留香久，

　　古砚微凹聚墨多’，

　　说的真有趣!”。

　　黛玉听后说道：

　　“断不可学这样的诗。

　　你们因不知诗，

　　所以见了这浅近的就爱，

　　一入了这个格局，

　　再学不出来的。

　　你只听我说，你若真心要学，我这里有《王摩诘全集》，你且把他的五言律读一百首，细心揣摩透熟了，然后再读一二百首老杜的七言律，次再李青莲的七言绝句读一二百首。肚子里先有了这三个人作了底子，然后再把陶、应、谢、阮、庾、鲍等人的一看。你又是一个极聪敏伶俐的人，不用一年的工夫，不愁不是诗翁了!”

　　黛玉之言，译作白话，就是说：若是想成为一只攻城狮中的战斗机，就不能仅仅囿于你会的某种计算机语言、某个熟悉的框架，而是需要：

　　先习作基本的算法和数据结构，

　　再了解操作系统原理，

　　再学习网络协议，肚子里面有了基本的数据结构的底子，明晓了操作系统的基本知识，对网络有了大体的认识，

　　再去学一门C++/JAVA等编译型语言，

　　继而

　　再去掌握一门动态语言如python/perl，

　　然后去探索你感兴趣的领域，

　　“独上高楼，望尽天涯路”了。

　　黛玉寥寥数语，

　　把诗歌那点事儿，

　　都给点透了。

　　但是要学好了，

　　实在是不易，

　　就如这些年北京城街头的房地产中介，

　　立块牌子，

　　上书某小区37平，

　　只需350!

　　那初入城的陈焕生，

　　见如此低价，

　　忙凑上前去，

　　却见这350的后面，

　　居然还有一个小小的“万”字!

　　真真是让人“垂死病中惊坐起”!

　　的确，

　　要参透王维佛偈、工部句法、太白气象，

　　再从陶潜清静无为一直习到清新如庾信、俊逸似鲍照，

　　是一个长期提高的过程。

　　凡事鲜有一蹴则可成的，一蹴而就那是国足后卫在踢球，一个大脚开到前场，余下的则不关本道爷清净。斯是说笑，但若是反躬自省，恐怕中枪者不在少数。

　　工程师不能只管“做完”手上被布置的那点任务，就不再去多用功夫了。请注意这里的用词，仅仅是“做完”，而不是“做好”。例如，有一批功能差不多的作业，“做完”就是不断把以前做的代码拷贝到当前的任务中，而“做好”则是把与业务无关的部分，总结提炼出来，写成公共函数，作成自己的库，更进一步可以辅之以“元编程”的技法，写一个小工具，自动生成代码。这样就可以避免做大量的重复劳动，在无尽的加班中燃尽青春的红烛。再者，在提炼、抽象、整合的过程中，个人能力也会得到质的提高。而若是图一时方便，大量去拷贝代码并不求甚解，那只会带来无尽的bug，使你陷入到无尽加班的死循环之中!

　　我们身边存在很多对个人能力提升毫无意义并且用正确的方法可以避免的加班，究其原因，就如黛玉所言：“断不可学这样的诗。你们因不知诗，所以见了这浅近的就爱，一入了这个格局，再学不出来的”。

　　如果不跳出现有的眼界，任你写再多的诗，也是徒费纸墨，见笑于茶歇酒座之间，例如民国军阀张宗昌(一说为韩复渠)就酷爱作诗，此列其代表作《咏泰山》供卿赏析：

　　“远看泰山黑乎乎，

　　上头细来下头粗。

　　有朝一日倒过来，

　　下头细来上头粗”。

　　诸君莫笑，请自省之，自己是否也在天天加班创作这类“黑乎乎”的项目呢?

　　见贤思齐焉，

　　见不贤而内自省也。

　　我们笑过“黑乎乎”，

　　则该想想自己如何跳出“三低”困境 ：

　　“工作效率低、工程质量低、个人能力低”。

　　一言以蔽之，就是“汝果欲学诗，功夫在诗外”。

　　除了耕好自己的那一亩三分地，还得去了解一下整个业务逻辑流程，是为所谓的“大局观”。有人不解，我若是了解了业务逻辑流程，要产品经理何用?然而事实是，大多数时候，你根本遇不到一个非常好的产品经理。当然关于产品经理的话题，@北冥乘海生这篇《产品狗的圣战》中已经讲得相当清楚了，于此不再赘言。再者，排除掉产品经理的因素，作为一个合格的工程师，你也应该知道自己在干啥，友军在干啥，对自己主攻的方向做到一个专字，对相关的方向做到一个博字，例如做前端的需要懂得商业产品业务以及后端有些什么样的逻辑，做后端的需要知悉日志中的各项参数对算法大致有些什么影响。从产品、技术、项目给谁用、业务细节等方面去思考，才能做到不过度设计、不遗漏逻辑，知道哪些部分优先级高、哪些部分可以暂时搁置、哪些部分会是性能瓶颈。

　　了解业务逻辑，熟悉自己所做的产品，这是从宏观的角度去解读“功夫在诗外”;而从微观的角度谈，工程师需要去了解自己项目中所使用到的各项技术。我们现在大量的使用开源软件、开源框架，如果对自己用到的技术不深入了解，仅仅满足于“会用”，那么不出问题则已，一出问题就只有“以手抚膺坐长叹”了。

　　“纸上得来终觉浅，绝知此事要躬行”，对于自己工作上涉及到的技术，一定要花时间去钻研，去读成体系的技术文档、去阅读学习优秀开源项目的代码。前些日子面试了一个号称搞大数据的人，此人侃侃而谈，教育我说，不要用mysql，要用oracle数据库，大有煮酒论英雄之势。问其原因，却憋不出个所以然来。又谈spark某个版本不好，复问其原因，该生说因为他写的某个job在这个版本上跑不过，换成新版本就可以跑通了。这类“人才”就很让人放心不下，属于“用打油诗冒充格律诗”一派，这也反映出当下受资本热钱追逐的互联网行业弥漫着的一股浮躁之风。其实静下心来读读优秀的开源项目是十分有裨益的，自顶向下可看到优秀软件的设计思路，能学到大师如何去抽象、解耦;自底向上可学到具体的优化方案，学到很多对细节的处理手法。如果有了这个实践“躬行”的过程，日积月累，可分云泥。

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

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

　“为人性僻耽佳句，语不惊人死不休”。

　　这是杜子美对自己遣词造句的要求，也可作为工程师给自己的勉励。过硬的工程质量、赏心悦目的代码、叹为观止的架构，就是工程师造出来的佳句。而去深入理解商业产品逻辑，钻研优秀开源项目，尝试做有深度有干货的技术分享，就是锤炼“佳句”之法。当然，这些都很难，但从来没有人说过，做一名优秀的工程师很简单!