伯樂線上注：本文來自文章作者徐凱（@徐凱-鬼道）的投稿（原文）。
———————————————————–
還未畢業就在百度實習了，兩年多的磨練，有被磨平的稜角，也有精彩的收穫；謹以此文獻給在百度並肩奮戰兩年多的兄弟姐妹們。忘不了離職日那場特殊的告別午餐；忘不了這兩年和你們的討論、爭論；忘不了腦海中你們的一個個優秀的細節。真想說無論“嫁”到何方，你們都是我的孃家人，我在天貓玩得蠻開心，請不要牽掛！
3月底，離職前的閒暇跑了趟蜀地，去九寨的山道上觸景生情（照片扔在我的微博相簿中@徐凱-鬼道），整理出這麼一篇，多是從細節總結出來的心得，不喜勿噴可輕拍，各種原因拖到今天才發上來。
大巴行駛在通往九寨的環山道上，望著奇險的山景，睡意全無……
團隊
隨著時間的推移，對於團隊的理解在不斷改變和加深。團隊中一些有趣的現象，比如：
- 誤解往往來自於缺乏溝通；原來的團隊中角色眾多，因為不瞭解其他角色的工作而發生的不愉快經歷是難免的，發生了就要溝通，大家坐下來聊聊天化解誤會就好了；這種事情我經歷過兩次，大家平心靜氣地談過後彼此更加信任，完全不會因為誤會而交惡。
- 團隊間的合作分工是有講究的，互相補充、制衡、各盡其責；在遇到緊急問題時也能表現出一貫的效率，最終推動問題的解決；這有點像《寒戰》中的情節。
- 曾問“技術和產品是什麼關係”，答曰“合作的關係”，何嘗是與產品，技術與任何角色不都是合作的關係嗎？
合作
筆者在百度的兩年經歷中，作為團隊中的客戶端（web前端+移動app）tech leader有一年的時間，需要頻繁和各類角色打交道，為了讓工作更加平滑地開展，需要了解每一種角色關注的焦點，與他們密切地合作。在一個產品的生命週期中，依次會接觸到這些角色：產品、設計師、前/後端、測試，之間還穿插著和老闆以及其他tech leader的溝通。
產品
需求的發起人。這群人能說會道，砍他們的需求就和要他們的命一樣；一般情況下“砍”不如“拆”，需求可以分期做，通常雙方都能接受；特殊的情況需要說明下，漂亮mm帶著水汪汪的大眼睛死死盯著你的時候，你的思路一定要保持清晰 :)
設計師
需求像水一樣流到設計師這裡。設計師一般分為互動和視覺；互動根據產品方需求提供互動稿原型，視覺在互動稿基礎上豐富頁面元素、配色、細節調整等；和設計師尤其是視覺要處理好退化的問題，真不是所有的設計師都能夠理解“漸進增強，平穩退化”的概念，這個需要溝通；之前在圓角問題上遇到過阻力，通過和視覺的溝通，視覺最終還是接受了前端的退化處理（border-radius）建議。
前/後端
之前，前端無論與業務端後端還是伺服器後端的合作都是很順暢的；前後端之間應該儘量解耦，只通過規範介面通訊是最理想的狀態；以java環境的業務端為例，jsp和freemarker（fm）二選一，應該選fm，因為fm是模板語言，儘管仍包含邏輯控制，但在前後端解耦上優於jsp；再進一步，fm和整站ajax通訊（js渲染頁面）相比，顯然選ajax，因為這樣前後端的耦合又更小了。
業務系統中是否選擇ajax需要根據業務型別來考慮，引用ER框架中的一段描述：
整站式Ajax應用不利於搜尋引擎抓取。故ER框架不適用於內容提供的WEB站點。
測試
見到過技術和測試掐架的場景，實際工作中這兩塊人的合作遠多於分歧；而且必要的掐架是對專案負責的表現，大家吵完架還是可以坐一桌吃飯的。有一點應該注意，不要等到專案快結束了想到讓測試介入，這樣測試很被動，對整個專案的進度也可能帶來風險；應該儘可能拆分手頭的需求，安排開發計劃，讓測試能儘早介入，技術和測試能夠交替完成各自任務是最理想的。
選擇團隊
- 新團隊機會多，但是可能會缺乏足夠的指導
- 新團隊往往沒確立在公司的地位，對個人晉升有可能造成影響
- 老團隊高手雲集，如果沒有好的新人成長計劃，要想殺出重圍也不容易
- 總體來說建議在老團隊學習，打下基礎，尋找合適的機會去新團隊闖一片天地
這些觀點仍然很泛，請具體情況具體分析。
帶新人
- 帶新人是老闆對你能力的認可，是好事
- 帶新人對自己的能力提高是顯著的，因為有一個機會把業務和技術的基礎回顧一遍，給自己查漏補缺甚至是理解得更深刻
- 安排好自己的時間，因為要想帶好新人是要花精力的
- 新人可能隨時會打斷你，要有忍耐力
- 如果新人太多，應該考慮找人幫忙帶，都攬下來的話對自己和新人都是不負責任的
結果導向
面試過的網際網路公司，HR都會來上一句“我們是結果導向的”，當時很配合的點點頭，以示理解（其實壓根沒聽懂）。兩年下來，我對結果導向的理解變成了：
- 上下班時間可以自由，但是要幹滿8個小時或更多，因為活就在哪裡，不離不棄
- 半年或年度考核時，KPI可能是唯一的評價標準
- 團隊的結果不夠好，個人肯定受影響，因為結果導向嘛
個人
承受壓力
儘管筆者在學校的時候已經做了一些小專案，初到公司環境還是有點發懵，人家提的需幾乎不加判斷地接受了，導致初期工作量奇大，壓力劇增。這個過程持續了1-2個月，高負荷的工作帶來的副作用竟然是承受壓力的能力變強了，好神奇！
仔細想想，壓力還是可以細分的，各個擊破：
- 高負荷工作量帶來的壓力；和主管客觀地溝通自己的上限，上限可以慢慢提高，要知道高負荷也可能給專案帶來潛在的隱患，比如累掛了
- 不熟悉的業務場景帶來的壓力；有時候看文件緩解不了壓力，就找人多問，給你演示，然後自己先用起來，再去看文件就會好一些
- 從未接觸過的技術帶來的學習壓力；和業務場景是一樣的處理，只有理解了“是什麼”，才能更快地掌握它
- 技術複雜性遠超過心理預期產生的壓力；冷靜下來！看清複雜性到底是結構很龐雜，還是某個演算法超難理解；如果是結構複雜理不清頭緒，嘗試下類似斷點除錯的辦法，還不行的話找人幫忙看看；如果是演算法太複雜，也務必找到資料或人詳細瞭解演算法的作用、使用場景、侷限性等，一般上來就直接看程式碼是很痛苦的
- 還遇到一種情況比較特殊，程式碼中用了很個性化的寫法（不知道魂淡當時怎麼想的），而且對方已經不在公司了，最後放棄了，只能重寫！這種情況比較極端，不過也給我們一個經驗，程式碼還是通俗點比較好，耍酷可以在github找個專案去炫耀肌肉
透明度
坊間流傳（原話找不到出處）程式有兩類：一類是設計得足夠簡單明瞭，以至於一眼看上去就知道沒有大的問題；另一類是設計得足夠複雜，以至於看不出是否有問題。想說的是，程式設計越是清晰透明，潛在風險越小，後期維護溝通成本也越小；筆者曾經有過這種念頭“設計寫得太明白，人家一看就明白會不會太沒深度了”，現在想想只能對那時的自己“呵呵”了。
推廣技術
優秀的程式設計師會推廣自己的技術
最初不理解，寫好程式碼不就行了嗎，幹嘛要搞這些？現實是：再好的設計和程式碼，沒有人瞭解的話就會被扔進歷史的垃圾堆！
對自己成果負責的話，就必須努力推動它被更多的人認可；這個推動的過程中往往又可以收到那些看似苛刻但卻極為重要的建議；這樣就走進良性迴圈中了。
推廣的方式有：團隊內分享、公司內部的技術刊物、外部的如部落格、微博、微信、IT諮詢站點……
經營部落格
最初是覺得“好記性不如爛筆頭”，但真正寫起來後發現寫部落格其實能夠深化那些停留在口頭的結論；寫部落格讓自己更有目的，會促使自己留心積累；功利一點看，無論面試新同學，還是自己被面，都提到了部落格，好的文章是極好的面試材料。
開源
筆者寫過一篇《為何/如何看原始碼》；如果時間允許，又是自己感興趣的可以考慮為專案貢獻程式碼、文件、測試case、demo甚至是宣傳推廣，能做的不僅僅只是coding。
筆者之前是閒著的時候去逛github，後來慢慢成了習慣，最後乾脆把自己所有的demo、讀書筆記、最後是所有文章和開源專案都扔到github上；公司立項前也會習慣地上去找找思路，也避免重複造輪子。
最好 vs 最合適
這是一個取捨的過程，或者說是在理想和現實中尋找平衡點；商業專案往往非常看重時效性，一種原因是合同已經簽好了，未按時完成就是違約，所以在這種壓力下很多時候就需要精簡設計，使用最合理的方案來做。
但是好在有“迭代”。
迭代
不同型別的公司，迭代週期差異巨大，比如電信裝置行業會是1年至3個月，而網際網路公司通常會是1個月至1周，甚至是按天釋出；很多迫於時間做出的折中方案往往可以在迭代中改進。
迭代的前提是產品本身允許增量釋出，一個有趣的對比是：計算機晶片和網際網路公司的門戶，顯然門戶更適合增量釋出；為什麼需要迭代呢？看到過這些原因：
- 產品需求太龐大；一次釋出的話將會把開發週期拖得很長
- 實驗性產品；丫不知道下一步要做什麼，先扔個版本出去看看市場的反應
迭代需要一個強有力的質量保證，單元測試和自動化測試都是保證質量的有效手段。
技術 vs 工具
比較認同《前端開發的工程之美》中技術和工具的對比：
對待技術和工具，技術自然是最基礎的，工具是照著“說明書”就可以很快上手，對工具不必太執念，否則會很快遇到成長的“天花板”。
解耦
書裡無數次提到要“解耦”，心想聯絡得緊密點有什麼不好。現實的專案中，尤其是在快速迭代的環境下，要是耦合非常緊，一個小改動就可能拉出一堆迴歸，等著哭吧。
大巴緩緩開進了九寨景區，望向遠方灰白的山脊，似乎看到了山腳下那五彩斑斕的海子……