百度兩年經歷：從學生到程序員【轉】

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

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個月，高負荷的工做帶來的反作用居然是承受壓力的能力變強了，好神奇！

仔細想一想，壓力仍是能夠細分的，各個擊破：

1. 高負荷工做量帶來的壓力；和主管客觀地溝通本身的上限，上限能夠慢慢提升，要知道高負荷也可能給項目帶來潛在的隱患，好比累掛了
2. 不熟悉的業務場景帶來的壓力；有時候看文檔緩解不了壓力，就找人多問，給你演示，而後本身先用起來，再去看文檔就會好一些
3. 從未接觸過的技術帶來的學習壓力；和業務場景是同樣的處理，只有理解了「是什麼」，才能更快地掌握它
4. 技 術複雜性遠超過心理預期產生的壓力；冷靜下來！看清複雜性究竟是結構很龐雜，仍是某個算法超難理解；若是是結構複雜理不清頭緒，嘗試下相似斷點調試的辦 法，還不行的話找人幫忙看看；若是是算法太複雜，也務必找到資料或人詳細瞭解算法的做用、使用場景、侷限性等，通常上來就直接看代碼是很痛苦的
5. 還遇到一種狀況比較特殊，代碼中用了很個性化的寫法（不知道魂淡當時怎麼想的），並且對方已經不在公司了，最後放棄了，只能重寫！這種狀況比較極端，不過也給咱們一個經驗，代碼仍是通俗點比較好，耍酷能夠在GitHub找個項目去炫耀肌肉

透明度

坊 間流傳（原話找不到出處）程序有兩類：一類是設計得足夠簡單明瞭，以致於一眼看上去就知道沒有大的問題；另外一類是設計得足夠複雜，以致於看不出是否有問 題。想說的是，程序設計越是清晰透明，潛在風險越小，後期維護溝通成本也越小；筆者曾經有過這種念頭「設計寫得太明白，人家一看就明白會不會太沒深度 了」，如今想一想只能對那時的本身「呵呵」了。

推廣技術

優秀的程序員會推廣本身的技術

最初不理解，寫好代碼不就好了嗎，幹嗎要搞這些？現實是：再好的設計和代碼，沒有人瞭解的話就會被扔進歷史的垃圾堆！

對本身成果負責的話，就必須努力推進它被更多的人承認；這個推進的過程當中每每又能夠收到那些看似苛刻但卻極爲重要的建議；這樣就走進良性循環中了。

推廣的方式有：團隊內分享、公司內部的技術刊物、外部的如博客、微博、微信、IT諮詢站點……

經營博客

最初是以爲「好記性不如爛筆頭」，但真正寫起來後發現寫博客其實可以深化那些停留在口頭的結論；寫博客讓本身更有目的，會促使本身留心積累；功利一點看，不管面試新同窗，仍是本身被面，都提到了博客，好的文章是極好的面試材料。

開源

筆者寫過一篇《爲什麼/如何看源碼》；若是時間容許，又是本身感興趣的能夠考慮爲項目貢獻代碼、文檔、測試case、demo甚至是宣傳推廣，能作的不只僅只是coding。

筆者以前是閒着的時候去逛github，後來慢慢成了習慣，最後乾脆把本身全部的demo、讀書筆記、最後是全部文章和開源項目都扔到github上；公司立項前也會習慣地上去找找思路，也避免重複造輪子。

最好 vs 最合適

這是一個取捨的過程，或者說是在理想和現實中尋找平衡點；商業項目每每很是看重時效性，一種緣由是合同已經簽好了，未按時完成就是違約，因此在這種壓力下不少時候就須要精簡設計，使用最合理的方案來作。

可是好在有「迭代」。

迭代

不一樣類型的公司，迭代週期差別巨大，好比電信設備行業會是1年至3個月，而互聯網公司一般會是1個月至1周，甚至是按天發佈；不少迫於時間作出的折中方案每每能夠在迭代中改進。

迭代的前提是產品自己容許增量發佈，一個有趣的對比是：計算機芯片和互聯網公司的門戶，顯然門戶更適合增量發佈；爲何須要迭代呢？看到過這些緣由：

• 產品需求太龐大；一次發佈的話將會把開發週期拖得很長
• 實驗性產品；丫不知道下一步要作什麼，先扔個版本出去看看市場的反應

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

技術 vs 工具

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

對待技術和工具，技術天然是最基礎的，工具是照着「說明書」就能夠很快上手，對工具沒必要太執念，不然會很快遇到成長的「天花板」。

解耦

書裏無數次提到要「解耦」，心想聯繫得緊密點有什麼很差。現實的項目中，尤爲是在快速迭代的環境下，要是耦合很是緊，一個小改動就可能拉出一堆迴歸，等着哭吧。