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

　　筆者按：

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

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

　　香菱對黛玉說：

　　“我只愛陸放翁的詩，’

　　重簾不卷留香久，

　　古硯微凹聚墨多’，

　　說的真有趣!”。

　　黛玉聽后說道：

　　“斷不可學這樣的詩。

　　你們因不知詩，

　　所以見了這淺近的就愛，

　　一入了這個格局，

　　再學不出來的。

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

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

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

　　再了解操作系統原理，

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

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

　　繼而

　　再去掌握一門動態語言如python/perl，

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

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

　　黛玉寥寥數語，

　　把詩歌那點事兒，

　　都給點透了。

　　但是要學好了，

　　實在是不易，

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

　　立塊牌子，

　　上書某小區37平，

　　只需350!

　　那初入城的陳煥生，

　　見如此低價，

　　忙湊上前去，

　　卻見這350的后面，

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

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

　　的確，

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

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

　　是一個長期提高的過程。

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

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

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

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

　　“遠看泰山黑乎乎，

　　上頭細來下頭粗。

　　有朝一日倒過來，

　　下頭細來上頭粗”。

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

　　見賢思齊焉，

　　見不賢而內自省也。

　　我們笑過“黑乎乎”，

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

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

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

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

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

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

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

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

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

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