技術工程師成長之其中一道

　　近來有業內朋友與我討論一些工作方法，聊得碎了些，今天閒來無事，索性再用文字的方式，簡單描述一下我的工作方法（Alien style）。當然，每個工程師都有自己的獨特的成長之道，所以，本文標題擬為其中之一道，下文如果您如果感興趣，就當消遣看看罷了。

　一、找準興趣點：認識自己

作為新手程式猿，首先要清楚的認識到，從什麼開始做起，才能讓自己覺得，工作，是一件非常開心的事情！

　　作為技術工程師，能選擇作為職業方向的也不少，比如：

• Web前端工程師（也稱FE，有的公司分的更細，比如Html/Css工程師、Javascript工程師等）

• 後端工程師（也稱RD，諸如：PHP工程師、Java工程師等等）

• 客戶端工程師（較多公司也將其歸為RD，諸如：iOS工程師、Android工程師等）

• 資料分析與挖掘（一些公司叫做BI或DI，平時產品業務會少一些，主要做一些大資料分析和處理，C或者Shell等指令碼用的會多些）

• 測試工程師（也稱QA，主要負責各種產品功能的白盒/黑盒測試，發現其中潛在的Bug，即質量檢測）

• 資料庫工程師（也稱DBA，屬線上運維工程師的一種，不過是著重負責各種資料庫的管理）

• 運維工程師（也稱OP，主要負責各種開發、測試、線上環境的運維，對線上服務穩定性提供保障；也是命令列用的最多的一個角色）

　　每一種角色，平時的工作狀態必然都是不一樣的，通過寫碼得到的成就感也是不一樣的。

　　作為一個新碼農，如果你希望自己寫的程式碼，能最直觀的變現成使用者看得見摸得著的東西，因此而獲得工作上的成就感，並且因此而愛上這份工作，那麼選擇Web前端工程師或者客戶端工程師，定是較好的。

　　倘若你更希望每天通過命令列，線上上各個伺服器之間跳來跳去，並且敲一堆別人看不太懂的命令，寫一堆別人看不太懂的指令碼，並因此獲得成就感，感覺更具有高逼格，那麼選擇運維工程師，一定沒錯了！

　　一些剛畢業的學生，很有必要在投簡歷求職之前，搞明白自己想做什麼；當然，也有大部分學生是通過校招進入到公司的，具體進去以後做什麼，可能都是公司隨機進行分配；對於這一部分的同學，如果在入職後一段時間內無法在工作上找到興趣點，就真該考慮申請transfer到其他Team了。

　　工作不應該僅僅是是掙錢養家餬口的一個工具，更應該是做人做事、成長道路上的一種樂趣。做自己喜歡的事情，再辛苦，也值得（切莫誤解：不是推薦大家加班，哈哈）。

　二、注重沉澱：充實自己

沉澱，是能最直接證明自己有收穫的一種方式，可以是文件沉澱、技術沉澱，等等

　　工作過程中，我們肯定會去做一些技術調研、方案分析與評審，這些東西便可以細細整理成文件，統一彙總到一個地方，比如團隊的wiki專欄下，自己能去review，組裡其他同學也能檢視到。

　　在一些大專案開展過程中，或多或少會針對某一類問題創造出比較優越的解決方案，可能是一種高效能的實現方式、也可能是一種高效率的除錯技巧，這些東西，稍微花點心思，都能將其作為一個類庫或工具提供給組內其他同學，以此作為技術點，沉澱下來。

　　簡單來說，可以把握這樣一個原則：

• 能用文字記錄的做事方式方法，就一定不要只靠口口相傳！用嘴巴傳來傳去，慢慢的也就走了形了，俗話說的好，好記性不如爛筆頭！

• 好用且實用的技術實現方式，能抽取成元件或類庫的，就儘量讓它最大限度的複用起來，並伴之以儘量詳細的使用文件！切莫針對類似的功能，在組內還不停的造輪子！

• 多看多寫多調研（有時候需要以玩兒的心態去學習）；但做技術的，若無實際產出，那隻叫瞎折騰，知其然而不知其所以然，效果並不佳

　　就我個人而言，無論是在百度，還是美麗說，所有我能夠去沉澱或者幫助大家一起去沉澱的東西，一定都不會放過。

　　如文件方面，我們搭建了團隊專屬了文件平臺，有專案設計與實現方案的評審文件、有專案總結的分享文件、有大型專案的排期節奏跟進文件、有技術的調研文件、有團隊技術分享的文件、更有團隊週報的歸檔專欄等等。

　　在技術方面，有符合團隊開發規範的整合解決方案、編譯工具、開發工具、前後端線上服務監控與報警系統、後端服務效能監控與分析平臺等等。

　　在玩兒技術的這一點，比如Web前端助手(FeHelper)就是在百度做前端的時候，玩兒Chrome擴充套件，一步步沉澱下來的。記得當時CSDN還舉辦了一個Chrome瀏覽器外掛開發中國區大賽，這FeHelper也迷迷糊糊拿了個三等獎。

　　再後來微信公眾號興起，在朋友圈鋪天蓋地的轉發都是隻有一個標題，很土；正碰上那一段時間2048小遊戲在PC和Wap上特別火，於是我也寫了一個放到自己公眾號，本著讓大家一起能夠在微信裡玩兒起來的心態，於是搞了一套基於微信公眾號分享的SDK，應用到這個小遊戲裡；這就是大家後來一直在使用的WeixinApi。在微信一直沒有推出官方版的js-sdk之前，WeixinApi造福了許多人。

　　任何形式能讓別人看得見摸得著的東西，才叫做沉澱，更是可以用來衡量價值的參考。

　三、做一個專案負責人：歷練自己

接受Leader的命令，並能單槍匹馬的把產品功能做完上線，這頂多能夠算得上能做事，離會做事、懂做事還差得遠

　　如果有一天你覺得自己能夠獨當一面去負責一個產品功能，不再需要導師和Leader的協助，那麼，是時候從更全的維度去歷練自己了：主動挑起一個專案，作為專案負責人，將其推行到底！

　　你至少可以從這幾個方面，得到更多的收穫，找到更多的成就感：

• 分析需求，判斷該專案需要涉及到的相關角色

• 組織各角色進行專案需求評審，並分析產品功能上的技術可行性、時間成本等

• 對需求進行功能模組合理拆分，落實前後端工程師的工作範圍

• 組織前後端工程師進行技術方案評審，並結合需求指定的上線時間判斷是否需要分優先順序分批次開展

• 合理分工，產出研發排期，並彙總聯調、自測、以及QA的測試工期，統一輸出專案的排期

• 跟進專案進展，結合排期Review專案產出，及時發現風險點，及時調整並通報

• 較大的專案，更有必要組織定期的站立會，以確保專案整體進展順利

• 專案過程中有臨時新增需求、或需求變更、或技術實現方案調整，更要能條理清楚的與所有角色進行分析，放眼大局觀，結合專案的整體上線要求，輸出最終的調整方案，保證專案穩健開展

• 測試前期，需要和QA明確其中的核心測試點，對於技術實現較複雜的地方，需要明確告知測試的力度，以免測試用例覆蓋不全

• 專案上線前，需要與運維工程師完成一切線上環境部署與配置，確保專案上線毫無障礙；對於涉及到邊緣產品較多的專案，更需要考慮到災備預案情況

• 專案完成測試後，如果是較大的產品需求，需要和產品同學討論，是否進行公司內部體驗，或者線上小流量（灰度）測試；並提供合理的問題反饋渠道，收集並整理使用者反饋，快速優化

• 專案上線後，需要密切關注服務穩定性，關注使用者反饋，穩定後，能進行專案上線通報

• 組織專案組所有角色進行專案總結，分析各角色在專案配合過程中出現的問題，總結經驗教訓；同樣也記錄專案中良好的問題處理方式，最後將專案總結分享到團隊；以此結束整個專案！

　　槍打出頭鳥，只要你是帶頭大哥，專案出現任何問題，Leader必然都會唯你是問，整個專案過程中，必然是會產生壓力的！但是，如果你永遠都不敢邁出這一步，又怎能知道自己能力究竟有多大呢？胸懷都是用委屈撐大的，大膽承擔，沒事兒！

　　所以，大膽去做吧，團隊一定都是更喜歡敢於主動挑起責任擔子的人的！

　四、做一個導師：學會育人

將所有成熟的工作方式，傾囊相授，也從新人身上做自我反省

　　優秀的做事方式，應該得到傳播，讓更多的人花更少的時間去變得優秀。工作中，最好的方式，就是在自己成長以後，做一個導師，協助新人一起成長，比如：

• 結合新同學的工作能力、業務範圍、技術興趣點，一同分析Ta成長過程中真實存在的阻力（或盲點）

• 為新同學量身定製短期、中期、長期的成長規劃，定期Review成長得失，及時糾偏

• 帶著新同學一起去嘗試一些大於Ta現階段工作能力的事情（業務功能、技術Topic等），幫助新同學挑戰自己，逐步突破自身的能力極限

• 學會放手，做好引導和後備支撐，讓新同學完完整整的去搞定一件事；栽了跟斗也不要緊，任何人成長的過程中都應該經歷一些坎坷；不經風雨，又怎見彩虹？

• 引導並督促新同學進行文件和技術各方面的沉澱，協助新同學在團隊裡找準自己的定位，站穩腳跟

• 引導新同學學會分享、學會與其他角色的溝通技巧、並逐漸學會把控專案的全域性觀

　　當然，你也需要從新人成長的過程中，不斷的反思自己，新人做的不夠好，是我的原因嗎？新人做的很好，我有功嗎？

• 新人某個功能沒做好，是不是自己沒有提前Review他的專案實現方案？或者自己給他的方案本身就是有問題的？

• 新人某個專案Delay很嚴重，是不是自己沒有多去Review他專案的進展？或者自己也沒搞明白專案的上線計劃是什麼？

• 新人某個專案Bug太多，是不是自己沒有盡到一個導師的指責，為他做好Code Review？或者自己平時的專案就是Bug頻出，新人只是效仿而已?

• 新人在其他角色面前總是沉默寡言，是不是自己沒有告訴他，應當大膽表達自己的想法？或者自己也不敢在人前多說話，自己也怕被拍？

• 新人在與其他角色溝通過程中，衝突不斷，是不是自己沒有教給他更好的溝通方式？或者自己也不會與人溝通，自己也經常與其他角色鬧得不愉快？

• 新人用一些很巧妙的方法把某件事情完成的很漂亮，得到大家的讚許，是不是自己給了他很好的引導？或者從這件事上面，你發現自己也有不如新同學的地方，你們需要互相學習？

• 新同學主動找你一對一溝通，進行成長總結，自我批評，這又是不是你平時的做事方式，讓他學會了積極領悟？再或者，你需要思考自己是否具備這樣的一個主動性，以及能夠批評和自我批評？

• 你對你的新同學足夠了解嗎？你對自己足夠了解嗎？

　　一個好的導師，永遠都不要擔心青會出於藍而勝於藍，因為這是好事，這是他的能力，更是你的本事！他若真能勝之於藍，說明他足夠優秀；我們要學會與優秀的人在一起，那樣才能更快的成長。

　五、密切關注行業動態：站得高才能看得遠

技術的革新都是非常迅速的，我們絕不能僅靠專案上的產出來充實和提高自己；碼農界聰明的人太多，必須把好的技術思想都吸收進來

　　逐漸的，需要將自己視作一個技術負責人。當然，若條件允許，可作為團隊技術負責；若團隊各方向劃分較細，可作為某業務方向技術負責人。

　　多分析團隊工作上遇到的一些技術難題，總結並歸類，網際網路行業發展至今，你所在團隊遇到的絕大部分問題，在別的公司必然都經歷過了。跳出來，想方法從各渠道瞭解發展較為成熟的公司、較成熟的技術Team都在用過什麼樣的方式來解決這一類的問題；雖然不能照搬照抄，但最起碼能從中得到更多的啟發。

　　新技術更新的很快，尤其在Web前端方面，不過多久就又出來一種新的解決方案。你應該作為一個技術痴迷者，密切關注行業的動態，看看人家都在搞什麼，為什麼會出現這麼多新的框架、類庫、工具等。舉個例子，搞明白：

• 在沒有jQuery之前，大家用原生的DOM也能把功能開發的很好，那為什麼會出來jQuery？它是為了解決什麼樣的問題而出現的？用它與不用它，在專案上會有什麼不一樣的地方？

• jQuery已經很好用了，那百度WebFE以前為什麼還要在公司內部搞一個Tangram？是單純的造輪子，還是因為它的確可實現各種Api定製化打包？對於jQuery的老手，如果使用Tangram，會有些什麼不一樣的地方？

• 後來大家又一致吹捧的AngularJS、Backbone.js、Ember.js這些又是什麼鬼？都是哪個公司哪個團隊基於什麼樣的問題才造出來的？他們用這些工具只是因為某一個產品功能，還是說這貨可作為一類通用的解決方案而存在？倘若要把它們引進到自己的專案組，是否真正適用？你能從中得到什麼啟發，大家又能學到什麼？

• Nodejs為什麼會出現？io.js為什麼又會作為其分支，單獨發展？後來為什麼又還是merge到了一起？

• 再比如跨平臺的移動開發工具，PhoneGAP、Titanuim、Xamarin、以後今年火起來的React Native，為什麼解決同樣問題的東西，會出來如此多，更新如此的快？最後出來的東西，是否都已經具備了先輩的優良品質？它們所針對的使用者群體是什麼？為何能得到大眾的青睞？它們和原生Native有何區別？

• PHP 7都發布了，為什麼你們先上服務還在使用PHP 5.3.29？升級PHP到最新版，在程式碼上是否需要做些相容？開發上是否和以前有變化？帶來的效能提升是否可大幅度減少伺服器的數量？

• 全文的搜尋引擎，Sphinx和Solr都是啥？索引的效率、搜尋的效能、對中文分詞的支援、以及對實時索引的支援，這些維度都有什麼不同？如果專案上需要使用，結合實際的需求，選擇哪一個更為合適？

• 再比如，你的團隊需要對線上服務進行多維度監控，市面上已經存在的Zabbix、Nagios、Open TSDB、或者Open Falcon，是否都知道這些東西能監控到那個層級？線上部署與應用的成本如何？後期的水平可擴充套件性又是如何？假如你要自己寫一個，你能否先畫出一張清晰的監控佈局圖？

　　總之，閒暇的時候，把技術眼界放寬些，多逛逛Github，或者一些國內外牛人的Blog，看看別人都遇到了什麼問題，都在解決什麼樣的問題，多做一些假設：如果這個問題是你遇到了，你會怎麼做？

　六、多思考多做事：多一些證明自我能力的機會

公司不是養老院，發你工資，你就必須創造價值。任何一份工作（一個產品功能、一個技術系統、一套開發規範、抑或一套工作流程）都必然有它的問題所在，多思考多分析，發現問題並解決問題，這樣才能創造價值，我們也才能成長！

　　也許你所在的團隊就好比一坨漿糊，一團糟，同事們都已懶得抱怨，只在乎工作能幹完上線就成。也許你所在的團隊一切都順風順水，同事們一團和氣，工作之餘有說有笑，開心的不得了，甚是滿足。

　　但是，世上沒有100分的人，必然也沒有100分的團隊；凡人皆有缺點，團隊亦然。不要被亂七八糟的團隊嚇到，也不要覺得團隊看起來太好了，便無從下手！

• 大家平時的開發方式是什麼樣的，是否都在重複的做一些體力勞動？如果是，是否可通過開發一些工具來自動化完成？

• 如果每位同學都自成一套開發體系，這樣的程式碼必然是很難維護的，團隊裡舊人去新人來，看著各式各樣的程式碼，哪有不抱怨的理？在開發流程和規範上必須要有統一的標準，推動並協助切實執行！

• 一個線上的技術系統，是不是都因為它是一個龐然大物，不敢輕易調整，所以對於新功能都是不斷的打補丁？久而久之，團隊裡的每位同學必然都只知道補丁，而不知道它真正的功能，真正的工作原理！所以必須要邁出第一步牽頭去重新梳理、歸置，將核心的部分獨立出來，展現它應有的功能！並伴之以詳盡的文件說明！

• 對於一個臃腫的業務系統，是不是大家都因為已經習慣了現在的開發、測試、部署等方式，所以不願意去做縱向拆分？如果這樣的一個系統已經拖慢了工作效率，那就必須動手梳理整治，讓它變成多個功能獨立的子系統，小而美，業務分明，專案之間更不易產生衝突，可維護性也能大大提高！同時推動團隊給每個子系統安排不同的owner！

• 如果以上技術團隊本身的問題不存在，則可以從產品功能的線上服務穩定性著手考慮。線上是否有頻繁的報警？各業務日誌是否都正常？使用者是否對某些常用功能有頻繁的反饋或吐槽？總之，能用工具自動監控報警的，就一定不要用體力解決。能夠通過工具平臺讓運營或產品同學自助查詢問題原因的，就一定不要再讓研發手工去操作。

　　只要願意靜下心來，從細小的點著手開始分析，發現問題，並利用一切可利用的資源，推動去解決它，不怕事小，只要一件件逐漸積累下來，定能體現出自己的價值，老闆們要的就是：因為有你，所以團隊變得更好！然而，你這樣的收穫，是無法簡簡單單隻用金錢就可衡量的，更是別人拿不去的財富。

　七、帶一個團隊：規範化流程化

當然，這也不是每個人都有這樣的機會能被提升為Team Leader；工作上可沒有裙帶關係，哥兒倆感情好就把團隊也交給你；必須是你平時的工作已經能充分證明，你具備了帶領這個Team一起發展的能力！

　　當然，在我看來，更重要的是做事，而不是在行政位置上的那個Title；只要你現在正在做的事情，就是帶一個團隊，至於是否是經理職稱，根本不重要。有時候一個小公司的技術總監，到了大公司，也得老老實實的做一線研發，不是嗎。你若真牛逼，公司又虧待你了，你走了，那隻能是公司的損失。所以，還是老老實實的做事吧，該來的自然會來。

　　作為一個業務&技術團隊的管理者，至少需要做這些事情：

• 按照團隊所負責的各業務進行清晰地規劃，切莫吃大鍋飯，還是小團隊作業的好；一支精銳的部隊，責任感會更強，每個人會更清楚自己要做什麼。

• 每條業務線，需求範圍明確，跨部門的需求，必定要有清晰的界限，保證組內各Team的工作能更順利開展

• 組內各小Team必須有統一的開發規範，攘外必先安內，如果自己Team內部的開發規範都一團糟，提供給第三方部門的介面還如何統一？

• 組內各小Team必須有統一的專案全流程，在每個環節都應該注重實實在在的產出（沉澱）

• 組內需要沉澱公共的元件庫、類庫、公共服務層，它必將形成一個團隊的主心骨，絕大部分的開發工作都能圍繞著它轉。如果有一個需求，團隊裡任何人不需要思考，直接就能完成，那就夠了。

　八、團隊培養與發展：健康並可持續發展

一個大於10人的團隊，必須考慮有效的梯隊建設，各方向的業務&技術負責人培養

• 在各業務方向上培養小組負責人，並讓該負責人培養自己的Backup

• 在團隊內培養技術方向負責人，源源不斷在團隊內輸出更多可供選擇的技術方案

• 團隊內形成良好的導師制度，Leader帶方向負責人，方向負責人帶一線研發；同時也需要將梯隊扁平化，打造一個無障礙的溝通和彙報機制

• 有團隊周例會制度，每週至少保證有一次機會，能讓大家聚集在一起，知曉團隊過去一週的專案整體狀況，以及下週的工作節奏

• 團隊內部必須形成良好的技術分享機制，至少每週一次，可以是大型專案的技術實現方案分享與評審、可以是大型專案的專案總結分享、可以是專案上某技術點的深入分析與應用介紹、可以是某工具平臺的構建思路或工作原理分析、可以是工作中必備小技能（奇淫技巧）的發散討論、也可以是行業前沿技術的調研報告分析、也可以是一些新技術的嘗後感、更可以是跨團隊甚至跨公司的技術交流。總之，需要讓大家切實感受到：在這個團隊，有東西可做，有東西可學！

• 與同學們進行不定期的一對一溝通，助其排憂解難，有問題也要直接指出來，並授之以漁！幫助同學們成長，這是做導師做Leader的職責！

• 明確合理的獎懲原則，公司不養閒人，也不養不長進的人；與優秀的人一起，團隊才能健康可持續的發展

• 不定期進行團隊建設（Team Building），可大可小，需要創造一些條件，能夠讓大家能夠聚在一起，討論一些工作之外的東西。身心愉悅了，哪還怕程式碼寫不好？

　　做Leader的，無論哪個Level，就應該想著：你何時才能把自己現在正在做的這些事情，都交給自己的Backup？

　　只有你自己能完全從團隊現在的事情上抽離出來了，你才有機會去考慮對團隊來說，更多更重要的事情，這是給Backup的機會，也是給自己的機會。

　九、學習一些其他的技術：跨界、全棧

俗話說，技多不壓身，用更多的技術知識來武裝自己，真有一天要上一個陌生的戰場，那也完全不在怕的。

　　當然，技術工程師成長過程中，全棧並不是必須要走的一條路，不過在深入掌握其中一門技術以後，眼界看得更開些，總是好事。

　　假設你是做前端的，一個前端Team能完全Hold住了，可以逐漸涉入後端，服務端、客戶端，做事的方式其實都一樣。不用花心思再去把每一門技術都重新學一遍，只要把該領域內的核心技術摸熟了、其中的工作原理掌握了、與其他領域的區別搞明白了，就夠了。

　　如果自身能力有限，領域，精一門兒足以，用同樣的做事方式，融會貫通，其他的技術領域必定不會太難。

　　回想自己工作的這麼幾年，先做Java，再做VB.Net、在做C#.NET、接著再做Web前端，一做就是三年；後來又學iOS、再轉Android；回過頭來又繼續帶Web前端Team、再帶PHP後端Team；說實在的，方法對了，事情也就好辦了。

　十、關注業務發展

很多行業大佬可都是技術出身啊！

　　技術改變世界，但沒有好的產品意識、沒有清晰的產品思路、沒有明銳的產品洞察力，不能將技術變現，總覺得自己技術很牛逼，又有多大用？感動了自己，感動不了別人。