還未畢業就在百度實習了，兩年多的磨練，有被磨平的棱角，也有精彩的收獲；謹以此文獻給在百度并肩奮戰兩年多的兄弟姐妹們。忘不了離職日那場特殊的告別午餐；忘不了這兩年和你們的討論、爭論；忘不了腦海中你們的一個個優秀的細節。真想說無論“嫁”到何方，你們都是我的娘家人，我在天貓玩得蠻開心，請不要牽掛！

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 工具

比較認同《前端開發的工程之美》中技術和工具的對比：

對待技術和工具，技術自然是最基礎的，工具是照著“說明書”就可以很快上手，對工具不必太執念，否則會很快遇到成長的“天花板”。

解耦

書里無數次提到要“解耦”，心想聯系得緊密點有什么不好。現實的項目中，尤其是在快速迭代的環境下，要是耦合非常緊，一個小改動就可能拉出一堆回歸，等著哭吧。

大巴緩緩開進了九寨景區，望向遠方灰白的山脊，似乎看到了山腳下那五彩斑斕的海子……