還未畢業(yè)就在百度實習了，兩年多的磨練雕沉，有被磨平的棱角集乔，也有精彩的收獲；謹以此文獻給在百度并肩奮戰(zhàn)兩年多的兄弟姐妹們坡椒。忘不了離職日那場特殊的告別午餐扰路；忘不了這兩年和你們的討論尤溜、爭論；忘不了腦海中你們的一個個優(yōu)秀的細節(jié)汗唱。真想說無論“嫁”到何方宫莱，你們都是我的娘家人，我在天貓玩得蠻開心哩罪，請不要牽掛授霸！
3月底，離職前的閑暇跑了趟蜀地际插，去九寨的山道上觸景生情（照片扔在我的微博相冊中@徐凱-鬼道）碘耳，整理出這么一篇，多是從細節(jié)總結出來的心得腹鹉，不喜勿噴可輕拍藏畅，各種原因拖到今天才發(fā)上來敷硅。
大巴行駛在通往九寨的環(huán)山道上功咒，望著奇險的山景，睡意全無……
團隊
隨著時間的推移绞蹦，對于團隊的理解在不斷改變和加深力奋。團隊中一些有趣的現(xiàn)象，比如：
- 誤解往往來自于缺乏溝通幽七；原來的團隊中角色眾多景殷，因為不了解其他角色的工作而發(fā)生的不愉快經(jīng)歷是難免的，發(fā)生了就要溝通澡屡，大家坐下來聊聊天化解誤會就好了猿挚；這種事情我經(jīng)歷過兩次，大家平心靜氣地談過后彼此更加信任驶鹉，完全不會因為誤會而交惡绩蜻。
- 團隊間的合作分工是有講究的，互相補充室埋、制衡办绝、各盡其責；在遇到緊急問題時也能表現(xiàn)出一貫的效率姚淆，最終推動問題的解決孕蝉；這有點像《寒戰(zhàn)》中的情節(jié)。
- 曾問“技術和產(chǎn)品是什么關系”腌逢，答曰“合作的關系”降淮，何嘗是與產(chǎn)品，技術與任何角色不都是合作的關系嗎搏讶？
合作
筆者在百度的兩年經(jīng)歷中佳鳖，作為團隊中的客戶端（web前端+移動app）tech leader有一年的時間纳本，需要頻繁和各類角色打交道，為了讓工作更加平滑地開展腋颠，需要了解每一種角色關注的焦點繁成，與他們密切地合作。在一個產(chǎn)品的生命周期中淑玫，依次會接觸到這些角色：產(chǎn)品巾腕、設計師、前/后端絮蒿、測試尊搬，之間還穿插著和老板以及其他tech leader的溝通。
產(chǎn)品
需求的發(fā)起人土涝。這群人能說會道佛寿，砍他們的需求就和要他們的命一樣；一般情況下“砍”不如“拆”但壮，需求可以分期做冀泻，通常雙方都能接受；特殊的情況需要說明下蜡饵，漂亮mm帶著水汪汪的大眼睛死死盯著你的時候弹渔，你的思路一定要保持清晰 :)
設計師
需求像水一樣流到設計師這里。設計師一般分為交互和視覺溯祸；交互根據(jù)產(chǎn)品方需求提供交互稿原型肢专，視覺在交互稿基礎上豐富頁面元素、配色焦辅、細節(jié)調整等博杖；和設計師尤其是視覺要處理好退化的問題，真不是所有的設計師都能夠理解“漸進增強筷登，平穩(wěn)退化”的概念剃根，這個需要溝通；之前在圓角問題上遇到過阻力仆抵，通過和視覺的溝通跟继，視覺最終還是接受了前端的退化處理（border-radius）建議。
前/后端
之前，前端無論與業(yè)務端后端還是服務器后端的合作都是很順暢的；前后端之間應該盡量解耦肄梨，只通過規(guī)范接口通信是最理想的狀態(tài)；以java環(huán)境的業(yè)務端為例金吗，jsp和freemarker（fm）二選一，應該選fm，因為fm是模板語言摇庙，盡管仍包含邏輯控制旱物，但在前后端解耦上優(yōu)于jsp；再進一步卫袒，fm和整站ajax通信（js渲染頁面）相比宵呛，顯然選ajax，因為這樣前后端的耦合又更小了夕凝。
業(yè)務系統(tǒng)中是否選擇ajax需要根據(jù)業(yè)務類型來考慮宝穗，引用ER框架中的一段描述：
整站式Ajax應用不利于搜索引擎抓取。故ER框架不適用于內容提供的WEB站點码秉。
測試
見到過技術和測試掐架的場景逮矛，實際工作中這兩塊人的合作遠多于分歧；而且必要的掐架是對項目負責的表現(xiàn)转砖，大家吵完架還是可以坐一桌吃飯的须鼎。有一點應該注意，不要等到項目快結束了想到讓測試介入府蔗，這樣測試很被動晋控，對整個項目的進度也可能帶來風險；應該盡可能拆分手頭的需求礁竞，安排開發(fā)計劃糖荒，讓測試能盡早介入，技術和測試能夠交替完成各自任務是最理想的模捂。
選擇團隊
- 新團隊機會多，但是可能會缺乏足夠的指導
- 新團隊往往沒確立在公司的地位蜘矢，對個人晉升有可能造成影響
- 老團隊高手云集狂男，如果沒有好的新人成長計劃，要想殺出重圍也不容易
- 總體來說建議在老團隊學習品腹，打下基礎岖食，尋找合適的機會去新團隊闖一片天地
這些觀點仍然很泛，請具體情況具體分析舞吭。
帶新人
- 帶新人是老板對你能力的認可泡垃，是好事
- 帶新人對自己的能力提高是顯著的，因為有一個機會把業(yè)務和技術的基礎回顧一遍羡鸥，給自己查漏補缺甚至是理解得更深刻
- 安排好自己的時間蔑穴，因為要想帶好新人是要花精力的
- 新人可能隨時會打斷你，要有忍耐力
- 如果新人太多惧浴，應該考慮找人幫忙帶存和，都攬下來的話對自己和新人都是不負責任的
結果導向
面試過的互聯(lián)網(wǎng)公司，HR都會來上一句“我們是結果導向的”，當時很配合的點點頭捐腿，以示理解（其實壓根沒聽懂）纵朋。兩年下來，我對結果導向的理解變成了：
- 上下班時間可以自由茄袖，但是要干滿8個小時或更多操软，因為活就在哪里，不離不棄
- 半年或年度考核時宪祥，KPI可能是唯一的評價標準
- 團隊的結果不夠好寺鸥，個人肯定受影響，因為結果導向嘛
個人
承受壓力
盡管筆者在學校的時候已經(jīng)做了一些小項目品山，初到公司環(huán)境還是有點發(fā)懵胆建，人家提的需幾乎不加判斷地接受了，導致初期工作量奇大肘交，壓力劇增笆载。這個過程持續(xù)了1-2個月，高負荷的工作帶來的副作用竟然是承受壓力的能力變強了涯呻，好神奇凉驻！
仔細想想，壓力還是可以細分的复罐，各個擊破：
- 高負荷工作量帶來的壓力涝登；和主管客觀地溝通自己的上限，上限可以慢慢提高效诅，要知道高負荷也可能給項目帶來潛在的隱患胀滚，比如累掛了
- 不熟悉的業(yè)務場景帶來的壓力；有時候看文檔緩解不了壓力乱投，就找人多問咽笼，給你演示，然后自己先用起來戚炫，再去看文檔就會好一些
- 從未接觸過的技術帶來的學習壓力剑刑；和業(yè)務場景是一樣的處理，只有理解了“是什么”双肤，才能更快地掌握它
- 技術復雜性遠超過心理預期產(chǎn)生的壓力施掏；冷靜下來！看清復雜性到底是結構很龐雜茅糜，還是某個算法超難理解七芭；如果是結構復雜理不清頭緒，嘗試下類似斷點調試的辦法限匣，還不行的話找人幫忙看看抖苦；如果是算法太復雜毁菱，也務必找到資料或人詳細了解算法的作用、使用場景锌历、局限性等贮庞，一般上來就直接看代碼是很痛苦的
- 還遇到一種情況比較特殊，代碼中用了很個性化的寫法（不知道魂淡當時怎么想的）究西，而且對方已經(jīng)不在公司了窗慎，最后放棄了，只能重寫卤材！這種情況比較極端遮斥，不過也給我們一個經(jīng)驗，代碼還是通俗點比較好扇丛，耸趼穑酷可以在github找個項目去炫耀肌肉
透明度
坊間流傳（原話找不到出處）程序有兩類：一類是設計得足夠簡單明了，以至于一眼看上去就知道沒有大的問題帆精；另一類是設計得足夠復雜较屿，以至于看不出是否有問題。想說的是卓练，程序設計越是清晰透明隘蝎，潛在風險越小，后期維護溝通成本也越薪笃蟆嘱么；筆者曾經(jīng)有過這種念頭“設計寫得太明白，人家一看就明白會不會太沒深度了”顽悼，現(xiàn)在想想只能對那時的自己“呵呵”了曼振。
推廣技術
優(yōu)秀的程序員會推廣自己的技術
最初不理解，寫好代碼不就行了嗎表蝙，干嘛要搞這些拴测？現(xiàn)實是：再好的設計和代碼，沒有人了解的話就會被扔進歷史的垃圾堆府蛇！
對自己成果負責的話，就必須努力推動它被更多的人認可屿愚；這個推動的過程中往往又可以收到那些看似苛刻但卻極為重要的建議汇跨；這樣就走進良性循環(huán)中了。
推廣的方式有：團隊內分享妆距、公司內部的技術刊物穷遂、外部的如博客、微博娱据、微信蚪黑、IT資訊站點……
經(jīng)營博客
最初是覺得“好記性不如爛筆頭”，但真正寫起來后發(fā)現(xiàn)寫博客其實能夠深化那些停留在口頭的結論；寫博客讓自己更有目的忌穿，會促使自己留心積累抒寂；功利一點看，無論面試新同學掠剑，還是自己被面屈芜，都提到了博客，好的文章是極好的面試材料朴译。
開源
筆者寫過一篇《為何/如何看源碼》井佑；如果時間允許，又是自己感興趣的可以考慮為項目貢獻代碼眠寿、文檔躬翁、測試case、demo甚至是宣傳推廣盯拱，能做的不僅僅只是coding盒发。
筆者之前是閑著的時候去逛github，后來慢慢成了習慣坟乾，最后干脆把自己所有的demo迹辐、讀書筆記、最后是所有文章和開源項目都扔到github上甚侣；公司立項前也會習慣地上去找找思路明吩，也避免重復造輪子。
最好 vs 最合適
這是一個取舍的過程殷费，或者說是在理想和現(xiàn)實中尋找平衡點印荔；商業(yè)項目往往非常看重時效性详羡，一種原因是合同已經(jīng)簽好了仍律，未按時完成就是違約，所以在這種壓力下很多時候就需要精簡設計实柠，使用最合理的方案來做水泉。
但是好在有“迭代”。
迭代
不同類型的公司窒盐，迭代周期差異巨大草则，比如電信設備行業(yè)會是1年至3個月，而互聯(lián)網(wǎng)公司通常會是1個月至1周蟹漓，甚至是按天發(fā)布炕横；很多迫于時間做出的折中方案往往可以在迭代中改進。
迭代的前提是產(chǎn)品本身允許增量發(fā)布葡粒，一個有趣的對比是：計算機芯片和互聯(lián)網(wǎng)公司的門戶份殿，顯然門戶更適合增量發(fā)布膜钓；為什么需要迭代呢？看到過這些原因：
- 產(chǎn)品需求太龐大卿嘲；一次發(fā)布的話將會把開發(fā)周期拖得很長
- 實驗性產(chǎn)品颂斜；丫不知道下一步要做什么，先扔個版本出去看看市場的反應
迭代需要一個強有力的質量保證腔寡，單元測試和自動化測試都是保證質量的有效手段焚鲜。
技術 vs 工具
比較認同《前端開發(fā)的工程之美》中技術和工具的對比：
對待技術和工具，技術自然是最基礎的放前，工具是照著“說明書”就可以很快上手忿磅，對工具不必太執(zhí)念，否則會很快遇到成長的“天花板”凭语。
解耦
書里無數(shù)次提到要“解耦”葱她，心想聯(lián)系得緊密點有什么不好。現(xiàn)實的項目中似扔，尤其是在快速迭代的環(huán)境下吨些，要是耦合非常緊，一個小改動就可能拉出一堆回歸炒辉，等著哭吧豪墅。
大巴緩緩開進了九寨景區(qū)，望向遠方灰白的山脊黔寇，似乎看到了山腳下那五彩斑斕的海子……
