近日喜獲珍島研發(fā)部供稿一篇，作者獨具匠心地從“香菱學詩”切入探討了研發(fā)部人員如何提高單兵作戰(zhàn)能力，字字珠璣，值得賞閱~

　　筆者按：

　　余加入研發(fā)部已近兩月，對整個部門有了初步了解，亦窺得公司全豹一二。個人在工程管理、團隊建設、部門協(xié)作方面都有些感悟，而想談談的是研發(fā)人員如何提高自己的單兵作戰(zhàn)能力這個主題。鄙司公眾號是一個內部交流暨對外展示的平臺，市場部諸位同仁在此筆耕不輟、競相弄潮，兄弟也來寫篇下水，發(fā)點研發(fā)部門的聲音。斯是新年，落下點感悟，若是能共鳴于諸，看到新年有新氣象，那便是功德一件了。

　　香菱學詩是《紅樓夢》中一段精妙的插曲

　　香菱對黛玉說：

　　“我只愛陸放翁的詩，’

　　重簾不卷留香久，

　　古硯微凹聚墨多’，

　　說的真有趣!”。

　　黛玉聽后說道：

　　“斷不可學這樣的詩。

　　你們因不知詩，

　　所以見了這淺近的就愛，

　　一入了這個格局，

　　再學不出來的。

　　你只聽我說，你若真心要學，我這里有《王摩詰全集》，你且把他的五言律讀一百首，細心揣摩透熟了，然后再讀一二百首老杜的七言律，次再李青蓮的七言絕句讀一二百首。肚子里先有了這三個人作了底子，然后再把陶、應、謝、阮、庾、鮑等人的一看。你又是一個極聰敏伶俐的人，不用一年的工夫，不愁不是詩翁了!”

　　黛玉之言，譯作白話，就是說：若是想成為一只攻城獅中的戰(zhàn)斗機，就不能僅僅囿于你會的某種計算機語言、某個熟悉的框架，而是需要：

　　先習作基本的算法和數據結構，

　　再了解操作系統(tǒng)原理，

　　再學習網絡協(xié)議，肚子里面有了基本的數據結構的底子，明曉了操作系統(tǒng)的基本知識，對網絡有了大體的認識，

　　再去學一門C++/JAVA等編譯型語言，

　　繼而

　　再去掌握一門動態(tài)語言如python/perl，

　　然后去探索你感興趣的領域，

　　“獨上高樓，望盡天涯路”了。

　　黛玉寥寥數語，

　　把詩歌那點事兒，

　　都給點透了。

　　但是要學好了，

　　實在是不易，

　　就如這些年北京城街頭的房地產中介，

　　立塊牌子，

　　上書某小區(qū)37平，

　　只需350!

　　那初入城的陳煥生，

　　見如此低價，

　　忙湊上前去，

　　卻見這350的后面，

　　居然還有一個小小的“萬”字!

　　真真是讓人“垂死病中驚坐起”!

　　的確，

　　要參透王維佛偈、工部句法、太白氣象，

　　再從陶潛清靜無為一直習到清新如庾信、俊逸似鮑照，

　　是一個長期提高的過程。

　　凡事鮮有一蹴則可成的，一蹴而就那是國足后衛(wèi)在踢球，一個大腳開到前場，余下的則不關本道爺清凈。斯是說笑，但若是反躬自省，恐怕中槍者不在少數。

　　工程師不能只管“做完”手上被布置的那點任務，就不再去多用功夫了。請注意這里的用詞，僅僅是“做完”，而不是“做好”。例如，有一批功能差不多的作業(yè)，“做完”就是不斷把以前做的代碼拷貝到當前的任務中，而“做好”則是把與業(yè)務無關的部分，總結提煉出來，寫成公共函數，作成自己的庫，更進一步可以輔之以“元編程”的技法，寫一個小工具，自動生成代碼。這樣就可以避免做大量的重復勞動，在無盡的加班中燃盡青春的紅燭。再者，在提煉、抽象、整合的過程中，個人能力也會得到質的提高。而若是圖一時方便，大量去拷貝代碼并不求甚解，那只會帶來無盡的bug，使你陷入到無盡加班的死循環(huán)之中!

　　我們身邊存在很多對個人能力提升毫無意義并且用正確的方法可以避免的加班，究其原因，就如黛玉所言：“斷不可學這樣的詩。你們因不知詩，所以見了這淺近的就愛，一入了這個格局，再學不出來的”。

　　如果不跳出現(xiàn)有的眼界，任你寫再多的詩，也是徒費紙墨，見笑于茶歇酒座之間，例如民國軍閥張宗昌(一說為韓復渠)就酷愛作詩，此列其代表作《詠泰山》供卿賞析：

　　“遠看泰山黑乎乎，

　　上頭細來下頭粗。

　　有朝一日倒過來，

　　下頭細來上頭粗”。

　　諸君莫笑，請自省之，自己是否也在天天加班創(chuàng)作這類“黑乎乎”的項目呢?

　　見賢思齊焉，

　　見不賢而內自省也。

　　我們笑過“黑乎乎”，

　　則該想想自己如何跳出“三低”困境 ：

　　“工作效率低、工程質量低、個人能力低”。

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

　　除了耕好自己的那一畝三分地，還得去了解一下整個業(yè)務邏輯流程，是為所謂的“大局觀”。有人不解，我若是了解了業(yè)務邏輯流程，要產品經理何用?然而事實是，大多數時候，你根本遇不到一個非常好的產品經理。當然關于產品經理的話題，@北冥乘海生這篇《產品狗的圣戰(zhàn)》中已經講得相當清楚了，于此不再贅言。再者，排除掉產品經理的因素，作為一個合格的工程師，你也應該知道自己在干啥，友軍在干啥，對自己主攻的方向做到一個專字，對相關的方向做到一個博字，例如做前端的需要懂得商業(yè)產品業(yè)務以及后端有些什么樣的邏輯，做后端的需要知悉日志中的各項參數對算法大致有些什么影響。從產品、技術、項目給誰用、業(yè)務細節(jié)等方面去思考，才能做到不過度設計、不遺漏邏輯，知道哪些部分優(yōu)先級高、哪些部分可以暫時擱置、哪些部分會是性能瓶頸。

　　了解業(yè)務邏輯，熟悉自己所做的產品，這是從宏觀的角度去解讀“功夫在詩外”;而從微觀的角度談，工程師需要去了解自己項目中所使用到的各項技術。我們現(xiàn)在大量的使用開源軟件、開源框架，如果對自己用到的技術不深入了解，僅僅滿足于“會用”，那么不出問題則已，一出問題就只有“以手撫膺坐長嘆”了。

　　“紙上得來終覺淺，絕知此事要躬行”，對于自己工作上涉及到的技術，一定要花時間去鉆研，去讀成體系的技術文檔、去閱讀學習優(yōu)秀開源項目的代碼。前些日子面試了一個號稱搞大數據的人，此人侃侃而談，教育我說，不要用mysql，要用oracle數據庫，大有煮酒論英雄之勢。問其原因，卻憋不出個所以然來。又談spark某個版本不好，復問其原因，該生說因為他寫的某個job在這個版本上跑不過，換成新版本就可以跑通了。這類“人才”就很讓人放心不下，屬于“用打油詩冒充格律詩”一派，這也反映出當下受資本熱錢追逐的互聯(lián)網行業(yè)彌漫著的一股浮躁之風。其實靜下心來讀讀優(yōu)秀的開源項目是十分有裨益的，自頂向下可看到優(yōu)秀軟件的設計思路，能學到大師如何去抽象、解耦;自底向上可學到具體的優(yōu)化方案，學到很多對細節(jié)的處理手法。如果有了這個實踐“躬行”的過程，日積月累，可分云泥。

　　閱讀好的開源軟件代碼、高質量的技術書籍，是提高個人能力的捷徑。可惜的是，我所了解的許多同學，僅僅是滿足于做完工作任務、加班做完工作任務、去網上搜代碼并且不求甚解地復制粘貼。較之于用提高工作效率的方式，更喜歡用蠻力去制造一堆看似沒有bug的代碼，而談到花點時間去做些研究性的工作，卻是以工作忙為擋箭牌。對于這一點，我深不以為然，項目是永遠做不完的，工作也是永遠做不完的，每天抽出兩個小時的工作時間，用于系統(tǒng)地閱讀分析優(yōu)秀的源碼和優(yōu)質的技術博客，逐步積累技術，不論是對公司的發(fā)展，還是對自己的成長，都是有百益而無一害。

　　再者，在團隊中做技術分享，亦是提高自我修養(yǎng)的妙法。整理資料、開壇論道，就需要去考慮所講的每個細節(jié)有無紕漏，在這個過程中，自己必然會促使自己去進一步理解認知，這就是所謂“溫故而知新”。這一點，更是見諸于有成功經驗的過來人：阿里內部就有規(guī)定，升任高級技術職位，必須有一定的團隊分享經歷。

　“為人性僻耽佳句，語不驚人死不休”。

　　這是杜子美對自己遣詞造句的要求，也可作為工程師給自己的勉勵。過硬的工程質量、賞心悅目的代碼、嘆為觀止的架構，就是工程師造出來的佳句。而去深入理解商業(yè)產品邏輯，鉆研優(yōu)秀開源項目，嘗試做有深度有干貨的技術分享，就是錘煉“佳句”之法。當然，這些都很難，但從來沒有人說過，做一名優(yōu)秀的工程師很簡單!