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

3月底，離職前的閑暇跑了趟蜀地，去九寨的山道上觸景生情，整理出這么一篇，多是從細節(jié)總結(jié)出來的心得，不喜勿噴可輕拍，各種原因拖到今天才發(fā)上來。

大巴行駛在通往九寨的環(huán)山道上，望著奇險的山景，睡意全無……

團隊

隨著時間的推移，對于團隊的理解在不斷改變和加深。團隊中一些有趣的現(xiàn)象，比如：

誤解往往來自于缺乏溝通；原來的團隊中角色眾多，因為不了解其他角色的工作而發(fā)生的不愉快經(jīng)歷是難免的，發(fā)生了就要溝通，大家坐下來聊聊天化解誤會就好了；這種事情我經(jīng)歷過兩次，大家平心靜氣地談過后彼此更加信任，完全不會因為誤會而交惡。

團隊間的合作分工是有講究的，互相補充、制衡、各盡其責(zé)；在遇到緊急問題時也能表現(xiàn)出一貫的效率，最終推動問題的解決；這有點像《寒戰(zhàn)》中的情節(jié)。

曾問“技術(shù)和產(chǎn)品是什么關(guān)系”，答曰“合作的關(guān)系”，何嘗是與產(chǎn)品，技術(shù)與任何角色不都是合作的關(guān)系嗎？

合作

筆者在百度的兩年經(jīng)歷中，作為團隊中的客戶端（web前端+移動app）tech leader有一年的時間，需要頻繁和各類角色打交道，為了讓工作更加平滑地開展，需要了解每一種角色關(guān)注的焦點，與他們密切地合作。在一個產(chǎn)品的生命周期中，依次會接觸到這些角色：產(chǎn)品、設(shè)計師、前/后端、測試，之間還穿插著和老板以及其他tech leader的溝通。

產(chǎn)品

需求的發(fā)起人。這群人能說會道，砍他們的需求就和要他們的命一樣；一般情況下“砍”不如“拆”，需求可以分期做，通常雙方都能接受；特殊的情況需要說明下，漂亮mm帶著水汪汪的大眼睛死死盯著你的時候，你的思路一定要保持清晰 ：）

設(shè)計師

需求像水一樣流到設(shè)計師這里。設(shè)計師一般分為交互和視覺；交互根據(jù)產(chǎn)品方需求提供交互稿原型，視覺在交互稿基礎(chǔ)上豐富頁面元素、配色、細節(jié)調(diào)整等；和設(shè)計師尤其是視覺要處理好退化的問題，真不是所有的設(shè)計師都能夠理解“漸進增強，平穩(wěn)退化”的概念，這個需要溝通；之前在圓角問題上遇到過阻力，通過和視覺的溝通，視覺最終還是接受了前端的退化處理（border-radius）建議。

前/后端

之前，前端無論與業(yè)務(wù)端后端還是服務(wù)器后端的合作都是很順暢的；前后端之間應(yīng)該盡量解耦，只通過規(guī)范接口通信是最理想的狀態(tài)；以java環(huán)境的業(yè)務(wù)端為例，jsp和freemarker（fm）二選一，應(yīng)該選fm，因為fm是模板語言，盡管仍包含邏輯控制，但在前后端解耦上優(yōu)于jsp；再進一步，fm和整站ajax通信（js渲染頁面）相比，顯然選ajax，因為這樣前后端的耦合又更小了。

業(yè)務(wù)系統(tǒng)中是否選擇ajax需要根據(jù)業(yè)務(wù)類型來考慮，引用ER框架中的一段描述：

整站式Ajax應(yīng)用不利于搜索引擎抓取。故ER框架不適用于內(nèi)容提供的WEB站點。

測試

見到過技術(shù)和測試掐架的場景，實際工作中這兩塊人的合作遠多于分歧；而且必要的掐架是對項目負責(zé)的表現(xiàn)，大家吵完架還是可以坐一桌吃飯的。有一點應(yīng)該注意，不要等到項目快結(jié)束了想到讓測試介入，這樣測試很被動，對整個項目的進度也可能帶來風(fēng)險；應(yīng)該盡可能拆分手頭的需求，安排開發(fā)計劃，讓測試能盡早介入，技術(shù)和測試能夠交替完成各自任務(wù)是最理想的。

選擇團隊

新團隊機會多，但是可能會缺乏足夠的指導(dǎo)

新團隊往往沒確立在公司的地位，對個人晉升有可能造成影響

老團隊高手云集，如果沒有好的新人成長計劃，要想殺出重圍也不容易

總體來說建議在老團隊學(xué)習(xí)，打下基礎(chǔ)，尋找合適的機會去新團隊闖一片天地

這些觀點仍然很泛，請具體情況具體分析。

帶新人

帶新人是老板對你能力的認可，是好事

帶新人對自己的能力提高是顯著的，因為有一個機會把業(yè)務(wù)和技術(shù)的基礎(chǔ)回顧一遍，給自己查漏補缺甚至是理解得更深刻

安排好自己的時間，因為要想帶好新人是要花精力的

新人可能隨時會打斷你，要有忍耐力

如果新人太多，應(yīng)該考慮找人幫忙帶，都攬下來的話對自己和新人都是不負責(zé)任的

結(jié)果導(dǎo)向

面試過的互聯(lián)網(wǎng)公司，HR都會來上一句“我們是結(jié)果導(dǎo)向的”，當(dāng)時很配合的點點頭，以示理解（其實壓根沒聽懂）。兩年下來，我對結(jié)果導(dǎo)向的理解變成了：

上下班時間可以自由，但是要干滿8個小時或更多，因為活就在哪里，不離不棄

半年或年度考核時，KPI可能是唯一的評價標(biāo)準(zhǔn)

團隊的結(jié)果不夠好，個人肯定受影響，因為結(jié)果導(dǎo)向嘛

個人承受壓力

盡管筆者在學(xué)校的時候已經(jīng)做了一些小項目，初到公司環(huán)境還是有點發(fā)懵，人家提的需幾乎不加判斷地接受了，導(dǎo)致初期工作量奇大，壓力劇增。這個過程持續(xù)了1-2個月，高負荷的工作帶來的副作用竟然是承受壓力的能力變強了，好神奇！

仔細想想，壓力還是可以細分的，各個擊破：

高負荷工作量帶來的壓力；和主管客觀地溝通自己的上限，上限可以慢慢提高，要知道高負荷也可能給項目帶來潛在的隱患，比如累掛了

不熟悉的業(yè)務(wù)場景帶來的壓力；有時候看文檔緩解不了壓力，就找人多問，給你演示，然后自己先用起來，再去看文檔就會好一些

從未接觸過的技術(shù)帶來的學(xué)習(xí)壓力；和業(yè)務(wù)場景是一樣的處理，只有理解了“是什么”，才能更快地掌握它

技術(shù)復(fù)雜性遠超過心理預(yù)期產(chǎn)生的壓力；冷靜下來！看清復(fù)雜性到底是結(jié)構(gòu)很龐雜，還是某個算法超難理解；如果是結(jié)構(gòu)復(fù)雜理不清頭緒，嘗試下類似斷點調(diào)試的辦法，還不行的話找人幫忙看看；如果是算法太復(fù)雜，也務(wù)必找到資料或人詳細了解算法的作用、使用場景、局限性等，一般上來就直接看代碼是很痛苦的

還遇到一種情況比較特殊，代碼中用了很個性化的寫法（不知道魂淡當(dāng)時怎么想的），而且對方已經(jīng)不在公司了，最后放棄了，只能重寫！這種情況比較極端，不過也給我們一個經(jīng)驗，代碼還是通俗點比較好，耍酷可以在github找個項目去炫耀肌肉

透明度

坊間流傳（原話找不到出處）程序有兩類：一類是設(shè)計得足夠簡單明了，以至于一眼看上去就知道沒有大的問題；另一類是設(shè)計得足夠復(fù)雜，以至于看不出是否有問題。想說的是，程序設(shè)計越是清晰透明，潛在風(fēng)險越小，后期維護溝通成本也越?。还P者曾經(jīng)有過這種念頭“設(shè)計寫得太明白，人家一看就明白會不會太沒深度了”，現(xiàn)在想想只能對那時的自己“呵呵”了。

推廣技術(shù)

優(yōu)秀的程序員會推廣自己的技術(shù)

最初不理解，寫好代碼不就行了嗎，干嘛要搞這些？現(xiàn)實是：再好的設(shè)計和代碼，沒有人了解的話就會被扔進歷史的垃圾堆！

對自己成果負責(zé)的話，就必須努力推動它被更多的人認可；這個推動的過程中往往又可以收到那些看似苛刻但卻極為重要的建議；這樣就走進良性循環(huán)中了。

推廣的方式有：團隊內(nèi)分享、公司內(nèi)部的技術(shù)刊物、外部的如博客、微博、微信、IT咨詢站點……

經(jīng)營博客

最初是覺得“好記性不如爛筆頭”，但真正寫起來后發(fā)現(xiàn)寫博客其實能夠深化那些停留在口頭的結(jié)論；寫博客讓自己更有目的，會促使自己留心積累；功利一點看，無論面試新同學(xué)，還是自己被面，都提到了博客，好的文章是極好的面試材料。

開源

如果時間允許，又是自己感興趣的可以考慮為項目貢獻代碼、文檔、測試case、demo甚至是宣傳推廣，能做的不僅僅只是coding。

筆者之前是閑著的時候去逛github，后來慢慢成了習(xí)慣，最后干脆把自己所有的demo、讀書筆記、最后是所有文章和開源項目都扔到github上；公司立項前也會習(xí)慣地上去找找思路，也避免重復(fù)造輪子。

最好 vs 最合適

這是一個取舍的過程，或者說是在理想和現(xiàn)實中尋找平衡點；商業(yè)項目往往非常看重時效性，一種原因是合同已經(jīng)簽好了，未按時完成就是違約，所以在這種壓力下很多時候就需要精簡設(shè)計，使用最合理的方案來做。

但是好在有“迭代”。

迭代

不同類型的公司，迭代周期差異巨大，比如電信設(shè)備行業(yè)會是1年至3個月，而互聯(lián)網(wǎng)公司通常會是1個月至1周，甚至是按天發(fā)布；很多迫于時間做出的折中方案往往可以在迭代中改進。

迭代的前提是產(chǎn)品本身允許增量發(fā)布，一個有趣的對比是：計算機芯片和互聯(lián)網(wǎng)公司的門戶，顯然門戶更適合增量發(fā)布；為什么需要迭代呢？看到過這些原因：

產(chǎn)品需求太龐大；一次發(fā)布的話將會把開發(fā)周期拖得很長

實驗性產(chǎn)品；丫不知道下一步要做什么，先扔個版本出去看看市場的反應(yīng)

迭代需要一個強有力的質(zhì)量保證，單元測試和自動化測試都是保證質(zhì)量的有效手段。

技術(shù) vs 工具

比較認同《前端開發(fā)的工程之美》中技術(shù)和工具的對比：

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

解耦

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

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