我在淘寶作前端的這三年 — 第二年

時間 2019-11-05

標籤淘寶前端三年 3年第二年简体版

原文原文鏈接

轉眼已經離職半年多了，早就想寫一篇工做總結，但因爲一直在準備英語考試，又須要處理結婚和房子裝修，沒想到一拖拖了半年。在淘寶作前端是我第一份簽了勞動合同的工做，在這我的才濟濟的大公司裏，接觸了很是多的人和事物，也學到了很是多的東西、開闊了眼界。因此仍是有必要作一個回顧和總結，一是本身備忘，二是或許對一些前端新人有所幫助，由於這篇文章會涉及到一些入職、職業規劃、招聘、晉升、離職等方面的信息。前端

因爲篇幅過長，三年總結將會分三篇發佈，當前是第二篇：git

第一篇（第一年）主要總結如何進入淘寶要用什麼樣的策略，如何站在老闆視角看問題，我眼中的阿里文化等（已發佈：juejin.im/post/5c74d4…）。程序員

第二篇（第二年）主要總結如何評審需求和推動項目，如何理解業務，飛冰項目的起源等（已發佈：juejin.im/post/5c7daf…）。github

第三篇（第三年）主要總結如何管理開源項目、推廣項目，對招聘面試的思考，以及技術危機，我離職的緣由，技術移民的考慮和將來規劃等（已發佈：juejin.im/post/5c811e…）。面試

內容平臺和達人平臺

2016 年 5 月份左右，淘寶海外交接以後，老闆交給我了新業務就是內容平臺和達人平臺。顧名思義，內容平臺就是管理淘寶內容的平臺，能夠寫文章、發微淘動態、上傳視頻等。達人就是內容創做者，他們除了在寫內容以外，還能夠在達人平臺上面管理本身的信息、查看等級和權益、查看收益等。算法

雖然他們很相關，但這卻分了兩個業務，背後分別對應兩個後端團隊，加起來 20 多我的，結果老闆就讓我一我的對接。諮詢以後緣由以下：shell

這兩個相關業務，最好是一塊兒搞比較高效，後端架構已經成型，但前端能夠安排一個或者一撥人。
咱們組開始負責中後臺技術產品 ICE（飛冰），咱們這個產品就是應對這種缺前端的中後臺系統開發需求的，因此這塊業務正好是最佳落地場景。藉助 ICE 模式，我僅做爲業務接口人，一些具體組件開發任務能夠分散到 ICE 團隊裏一塊兒開發來解決。

因此我迎來了最忙的幾個月，極大的考驗了任務規劃能力和工做能力。由於兩個業務平臺有一些子頁面，用了 KISSY、KISSY Editor、Vue、自研編輯器還有無線端頁面，代碼比較亂。此外因爲以前就知道要交接，一些業務需求直接 hold 等到交接給我以後再排期開搞，這部分老需求仍然須要在以前代碼裏改。基本上白天處處評審需求排期，晚上開發的狀態。與此同時，內容平臺和達人平臺都但願將前端直接重構掉，換代升級，這是個至關大的工做量。在這麼忙的狀況下，淘寶頭條還拉我評審一個比較大的需求。編程

我給淘寶頭條一個項目評了一個三個月的工期

2016 年 6 月那會，頭條類業務在迅速崛起，淘寶頭條也被給予厚望，屬於重點業務。它主要是一些頭條新聞、導購類內容，由於頭條創做者在達人平臺進行入駐並進行創做和管理信息，因此屬於咱們達人平臺的業務方。此次頭條業務方有一堆加強富文本功能的需求和一個新的入駐填表流程系統的需求提交了過來。後端

富文本算是前端挺麻煩的東西，這個需求要在老富文本代碼上面擴展這些 UI 和功能，特別是還有一項功能：支持 Word 文檔複製粘貼，支持裏面的多張圖片一塊兒上傳。 這個功能我搜了下技術方案，只有 QQ 空間實現了，實現方式是須要裝瀏覽器插件獲取本地文件系統權限，而後掃 Word 文檔 Cache 目錄發現對應圖片文件而後上傳。開發這個功能不是前端範疇了，給我半年也夠嗆搞定的。使勁砍了下需求發現砍不動，挨個評審下來加上現有高優先級需求差很少得開發三個月。跟他們說了以後，一屋子驚訝的叫聲，遠遠超出了他們的預期。瀏覽器

回到工位沒過多久，老闆很嚴肅的叫我過去白板牆那邊，說是大老闆圓心找我有事情，到了一看原來是業務方老闆直接一封郵件投訴到我大老闆這邊了，他們指望月底上線，怎麼給他們排了三個月。因爲是新交接，對個人技術能力有極大的質疑。

因此老闆叫我過去一塊兒評估看看這個需求究竟是什麼狀況。因此我就把需求和現狀都描述清楚，通過兩位老闆的評估，確實少不了開發量。目前淘寶富文本仍是老 KISSY 的，沒有 React 體系新的富文本，對內容體系的確是缺一套，因此圓心老闆就把這個富文本的任務交給我了。

最後的結論就是新加了一個高級前端工程師跟我一塊兒作，優先級調到最高，並對每一個需求點評估時間列出來，從新開評審會，讓業務方本身對照時長砍需求。最後砍掉了不少需求，那個需求降級爲從網頁上支持複製多張圖片到編輯器，不懂技術的人可能想不通，都是複製多張圖片到編輯器，爲何網頁上能夠作，Word 就不能作？但其實網頁複製解析 HTML 就能夠拿到圖片 URL 而後調接口上傳淘寶 CDN，可是從 Word 文件複製則涉及本地文件讀取了，受限於瀏覽器權限，技術成本徹底不同。

項目開始以後，果真發現了不少風險：

交接混亂期，平臺方沒有 PD 出面控制需求，徹底根據業務方的需求的來開發。業務方只會考慮自身的需求，極可能破壞平臺功能的一致性，給其餘業務方功能帶來一些風險。
沒有 PM（通常是後端承擔，由於後端技術方案一般會比前端複雜，須要考慮的事情更多），絕大部分人都認爲這個項目主要是前端的工做，因此需求都來找我，後端不多參與評審，更沒有一個明確的 PM 角色。

我是這樣消除風險的：

跟另外一個同窗合理分工，拆開後互不依賴， 本身選擇了比較噁心的富文本和老後臺部分（由於之後要負責作新富文本）。
加班沒得跑了，須要以最大精力先解決最具風險和不肯定性的部分。 勞動節前兩天，我直接全天在家從早開發到晚上，搞懂原來富文本的代碼，開發掉了絕大部分有風險的需求。第三天才放鬆休息了一天。結合其餘積攢需求，這段時間基本天天晚上回家都工做，開發到凌晨兩點才睡覺。
主動擔任 PM 角色，併發送日報，抄送業務方和老闆，指明今天進度，被阻塞的問題和誰來解決，以及當前項目風險。 在日報裏明確指出了不少後端相關可是沒作或者不知道的工做，並給出解決方案。這種方式可讓業務方、老闆和項目組成員都及時明確風險點，並盯住對應問題處理人使其儘快完成，減小阻塞。

最後結果：

咱們兩我的分別開發了一個月搞定上線。若是沒砍掉不少需求，一我的開發，的確須要三個月，我評估的工期沒有問題。
業務方對個人印象從水平不行轉變成了靠譜。 由於爲了項目進度加班的日報均可以收穫得，而且能夠很負責的去指出一些風險追蹤其餘人的進展來保障項目進展。今後以後這個業務方 PD 提過來須要我開發的需求，再也沒有質疑過個人排期。

回頭來看，若是再回到一開始，即使是冒着被投訴的風險，我仍是會如實排期三個月。強行縮短工期只能壓死本身同時增長上線風險。 固然前提是真有很大工做量，能經得住老闆的評審才能夠，不然可能會認爲你工做能力真的不行。

如何能評估比較準的工期呢？一個很簡單的公式送給你們：

需求很是明確並且常常這樣作：本身評估時間 * 1.5
需求不夠清晰，有可能變，可是代碼和技術方案熟悉：本身評估的時間 * 2
需求不夠清晰，代碼和技術方案也是新的，須要探索：本身評估的時間 * 2.5 or 3

本身評估的時間通常會留點 buffer，自我感受應該沒問題，實際上開發過程可能會有各類會議、需求和技術方案變動或者突發事件。因此多留一點 buffer 會更好，由於這個時間點多是下游運營活動上線時間點，評估後業務方以爲太長能夠砍需求拆成兩期或者調整上線預期，但一旦設置了時間點，不該該跳票。若是你比預期早完成上線，皆大歡喜，若是你一次次的告知業務方還須要延期一兩天，效果正好相反。

ICE（飛冰）艱難的落地

開發完淘寶頭條項目以後，也快消化完交接時積攢的那些需求，便開始着手新版內容平臺和達人平臺的開發。這時候 ICE 基礎組件部分也已經經過包裝 Fusion Next 完成初始版本，腳手架和命令行工具也已經完成，開始落地業務並抽離業務組件。

ICE 的思路是這樣推導的：

後端開發資源要比前端開發資源多。
後端團隊自身就有不少後臺管理系統、業務運營系統的開發需求，可是在淘寶，這種非對外的內部管理運維繫統是不會投入前端資源的。
因此有些後端開發須要學習前端技能，可是受限於精力和尋找資料的能力成本比較大，並且學習到的前端技能也比較亂，從已有的後臺系統來看，廣泛很醜很難用。有的用 jQuery，有的用 Bootstrap 等，技術方案、用到的組件各異。開發成本大，交接維護成本高。
後端同窗並不懼怕編寫 JavaScript 的業務邏輯，廣泛最怕的是寫 CSS 調整樣式。
在新時代，先後端界限已經模糊，後端也須要具有一些前端開發知識。若是一塊功能一我的作好先後端功能，此時效率是最高的，由於不須要溝通接口等。
React 的寫法相比 jQuery 等更有「編程」的感受，更符合 Java 開發的習慣，而基於基礎組件，開發同窗不須要編寫大量樣式也能夠開發出比以前美觀一點的效果。

因此 ICE 最初就是基於 React 的一堆基礎組件 + 業務組件 + 腳手架 + 前端教學文檔 + 前端答疑羣。 咱們的賣點就是：你係統裏的複雜組件若是能夠被其餘系統複用，那麼咱們來開發；咱們提供前端技能培訓和答疑，在咱們答疑羣裏問的任何前端問題均可以被咱們解答，複雜問題咱們提供上門服務。

好像挺正確挺好的，但在後端視角就是：明明是前端領域的工做，如今要給我來作了，無緣無故給我加了不少工做量。因此最初的推廣十分艱難，尤爲是在重構達人平臺的這個過程。

這個問題跟人的關係很大，有的開發在以前公司就須要作一部分前端工做，有了 ICE 他們反而會感謝，由於不用本身調不少 CSS 和組裝 Copy 來的 jQuery 代碼。而沒有 Web 開發經驗且不肯意學習前端相關知識的同窗，則會至關抵觸。解決這個問題只能自上而下，經過高層溝通確認這種合做模式，而且傳達給下層這是平常工做的一部分，而不是額外的工做。而咱們前端能作的，就是儘量服務好。咱們提供的答疑服務是上門的，若是你遇到了很差描述的問題，咱們會直接到你工位上解決。並且咱們的答疑釘釘羣不會設置輪流排期，由於這樣可能會產生推脫的狀況，咱們的規則是誰看到馬上跟進解決。固然這樣對咱們的成本是很高的，有時候兩我的可能同時在排查一個問題。在夏天咱們甚至舉辦了個 ICE 送清涼的活動，拿着咱們團隊獲得的獎金買了不少雪糕分三天免費發放給後端，來提高知名度和好感。

達人平臺高層對接溝通好了，願意嘗試這種新模式，可是須要我入駐項目室實時答疑解決問題兜底。項目組成員作好分工以後，就開始分別開發，踩了很是多的坑，苦不堪言。好比：Mac 電腦用 shell 腳本一鍵配置環境很順利，但在 Windows 電腦上讓開發同窗本身手動配置 Node 開發環境就要命了，有的安裝錯了應用和版本，有的漏裝東西，因此後來我用 bat + rar 自解壓包裹了穩定版本的必備軟件，搞了個 exe 文件方便安裝，緩解了這個問題；當時 Fusion Next 的組件也剛開發出來，bug 很是多，咱們提了很是多的反饋和 MR 來修，可是給開發的印象就很是不穩定。有一次甚至阻塞了半天，瘋狂朝我吐槽，咱們做爲中間商十分委屈，也曾經冒出過無數次的念頭，打算將底層組件從 Next 切回 Ant Design 。但 Fusion Next 項目成員修復還算積極，咱們不斷開「批鬥會」，他們也虛心接受快速調整。站在如今角度來看，用 Fusion 是對的，由於 Ant Design 重 Design，皮膚覆蓋、配置十分困難，而各個團隊、BU、業務的後臺，是有明確主題需求的，而 Fusion 的一大優點就是全鏈路、體系化的解決了一套組件不一樣風格定製的功能。（後續我會製做一些相關內容詳細介紹）

這段時間各方面壓力都很大，ICE 小組忙着開發新組件、腳手架和修 Bug，開發同窗用新東西開發不適應、效率低問題不少須要協助，我又接了開發內容平臺須要的 ICE 富文本組件的工做。不一樣於頭條項目開發到晚上兩點，我調整了做息，基本早上 7 點多到公司趕忙吃飯，開始給內容平臺開發富文本組件到 9 點多，而後進達人平臺項目室而後開發達人平臺到晚上。因爲項目室有十個後端，白天基本就是轉着圈解決他們的前端問題，晚上拿他們的代碼來優化樣式補齊需求提測。（站在如今的角度來看，早上而不是晚上開發富文本組件這個安排是十分必要、合理的，由於自控力、精力在早上是最好的，最適合這種邏輯、代碼複雜的工做，也比較安靜。關於自控力和工做節奏，我將會在第三篇詳細講解。）

即使這樣，仍是有兩個後端同窗爆發了，直接開始對我攻擊每天吐槽，有一個同窗一旦遇到小問題，就直接用電話釘我，搞得我都無法正常工做了。雖然發生了衝突，可是阿里巴巴規定了不能在公司裏打架，那麼：

跟同事產生了工做衝突應該怎麼辦？

跟同事產生衝突，顯然是不能打架，應該儘早明確問題所在，對事不對人，解決問題。 若是有必要就須要找老闆來解決。當我跟老闆反映這個問題以後，老闆和 Winter 叫上他們倆和我就一塊兒找休閒吧沙發開了個小會。

重點聊了下他們的感覺和問題，並就問題在高層的角度作了些解答和解釋，最後給出了一些咱們這邊的解決方案和排期。問題就順利的解決了，他們願意恢復到正常的開發節奏，後來跟個人關係也變的挺好，合做也挺愉快了，直到離職後還常常朋友圈互動。

不少時候解決不了的問題要趕忙找老闆，若是本身硬碰硬可能拔苗助長，有高 P 出面調解和分析，看問題的角度可能就變了，問題就解了。常常看到前端討論羣裏有吐槽跟產品經理衝突硬碰硬的狀況，其實沒有必要，能夠反饋給老闆讓他給些建議或者讓他聯繫產品的老闆解決。工做就是工做，通過協商和調整，找到你們最舒服的工做方式纔是正解。由於衝突打架最後被開纔是十分悲劇也是毫無必要的。

就好比前段時間那個「APP 主題須要按照手機殼顏色來更換」的需求，致使程序員和產品經理大打出手最後雙開，其實不必。徹底能夠從業務自己來梳理下這個需求，查看這個功能的上線是否能夠爲當前業務的核心指標帶來價值，它的需求來源是什麼。若是說但願經過更多變化來增長 APP 的活潑程度，吸引用戶，那麼徹底能夠拆兩期，第一期先隨機改變主題或者支持用戶手選，看看業務指標是否能夠上漲。若是數據沒有上漲也不須要作第二期了，上漲以後能夠繼續優化。若是是產品經理或者老闆強行要作，那麼能夠按照難度評估個很長的時間，好比須要半年。可讓老闆介入評估（開發經驗更豐富，更有話語權）並向更上級反饋這個研發成本，若是能夠接受這種成本，技術團隊就能夠開始專一研發相關功能了，徹底不必打架。

阿里基層領導應該是壓力最大的一批人

轉眼就到了雙十一了，原定計劃六週的重構項目，結果延期了五週多的時間才上線。裏面有各類緣由交織在一塊兒，有些是由於遇到了老舊系統歷史遺留問題，有的是跨團隊協做沒溝通好，也確定有一部分緣由是使用 ICE 新方案增長了後端開發工做量。但最終結果就是沒有如期上線，並且直接耽誤了雙十一的需求。

因此業務方組織了一場反省會，召集各方開發進行此次項目的 Review。我和老闆也參加了進行自我批評，老闆可能場面見的比較多，自我反省很天然，輪到我，我只能故做鎮靜的哆哆嗦嗦自我反省說：基於這種項目研發資源配比和協做模式，我已經盡了全力了。今後我就挺關注本身需求的時間點，儘量少延期，由於發生這種事情真是太尷尬了。

無論如何，最終結果是達人平臺業務後端交接，原來團隊規模縮小了，成員有些離職了有些轉崗了，業務方也換了一些新的人進來搞這個業務。

其實淘寶前端團隊自己也有過幾回不成功的大項目，最後結果基本上是都是團隊拆散，一些離職一些轉崗。畢竟辛苦作了一年沒作成功，都很不甘心，也不肯意留下。

這讓我體會到了團隊間競爭的殘酷，一般以年爲單位，作好了，晉升、獎金、擴大規模，作很差，拆散、換人、離職。但正是這種節奏和變化，能讓阿里這條大船充滿活力，快速試錯調整，立於不敗之地。

一般作的好的同窗，會逐步虛線帶領小組處理一條業務線或者一個領域的工做。持續作得好，下一年可能就會獲得晉升，組織結構調整會讓你實線負責一個團隊，來負責一條業務線。這時候就要求就更高一些，並且你要對結果負責。除了作好目標設置、規劃和推動項目，還要關心人員流失和晉升狀況。有時候項目節奏高壓了，人員就流失了，缺人了還要加大精力來給本身團隊招聘；項目走偏或者進度落後，就會被認爲沒達到目標從而被打 3.5 或者 3.25，這樣人員得不到晉升看不到但願也沒有不少年終獎，極可能離職或者轉崗。若是上層認爲你沒有足夠能力，也會將團隊拆散重組。

其實最難受的是本身打拼了一年，竟然以這種結果收場。

雖然此次業務落地並不算是成功，可是對於 ICE 則是一次全方位的測試和升級。通過各類問題的解決，ICE 直接成熟到能夠對其餘團隊進行推廣。在淘寶通常雙11、雙十二大促完成以後，團隊會進行規劃和梳理並着手開發完善本身的運營平臺，因此咱們 ICE 小組搖身一變成了「地推小分隊」，帶着我作的教學分享 PPT 和 Demo 開始聯繫各個淘寶後端團隊的 TL 約時間分享推廣 ICE，讓他們在新一年的平臺建設開始使用 ICE，再次有種內部創業的感受。

如何理解業務

今年也開始關注業務，思考業務。業務能力應該是程序員除了技術以外，最具價值的能力，也是最必要的。由於技術自己很難賺錢，業務落地才能賺錢。當程序員具有了業務和產品能力，纔可能選取業務和技術的折中點，又快又好的支撐業務，帶來價值和效益。懂產品和業務（甚至交互設計）的技術，更容易跟其餘工種進行溝通，用通俗易懂的方式介紹技術實現和難度，能夠提高在企業中的自身地位和價值。此外，對於架構師，理解業務也是必備能力。

2016 年 12 月的有一天晚上參加了 HR 組織的一個業務能力培訓的會議，分享人是展炎和個人老闆元彥，他們都是帶領偏業務的團隊，因此對業務的分析理解能力也很強。雖然以前也一直關心業務，但總感受似懂非懂、暈頭轉向。正是這天晚上的展炎的分享《如何瞭解業務&產品》，給了我一條分析業務的通用方法論，今後再也沒有似懂非懂的感受。

分析業務最核心的方法和關鍵點，就是梳理出這條業務的總體鏈路，並查看是否能夠造成閉環。 一個完整的鏈路閉環包括：業務目標、業務思路、產品方案、跟蹤和調整。 簡單的說，一個業務靠不靠譜，先要看業務目標是否契合大目標或者有用戶需求，其次還要有業務開展的思路，以後產品針對這種思路的具體產品方案，最後就是業務落地、跟蹤結果並分析，再來看是否須要調整或者放棄。在這個閉環中最好能夠本身產生價值（錢）本身消費持續升級。下面舉個具體的例子：

問題：爲何淘寶要大力發展內容業務？內容業務是不是一個能夠持續發展的核心業務？

分析：首先從大的閉環來看，阿里巴巴集團的核心目標是讓天下沒有難作的生意（口號），淘寶在這個閉環中是連接中小賣家和買家的橋樑。因此在淘寶業務中，成交量就是核心指標之一，由於成交量越高越接近生意不難作的目標。 提升成交量有不少途徑，對外掛廣告（阿里媽媽、優酷、微博）、提升淘寶搜索準確度、相關商品算法推薦、搞活動大促都是一些沿用不少年的方法，可是這些途徑用戶購物目的明確，快進快出，基於這些方式很難再壓榨更多成交。可是內容、視頻、直播這種新的內容形態正好彌補了這個領域，這些內容形態不一樣於商品，好的內容可能吸引用戶使用淘寶，用戶使用時間增加就意味着有更多商品信息暴露給用戶，提高購物的可能性。此外文章、視頻、直播等更能讓消費者熟悉瞭解商品，提升轉換率，甚至能夠憑空爲用戶創造需求產生購物行爲。

因此淘寶內容業務在整個阿里巴巴業務大環中是站得住腳的，也能夠推導出淘寶內容業務的核心業務目標是：用高質量的內容吸引用戶觀看從而提高手淘的用戶使用時間，同時經過內容推薦和算法推薦促進成交。從內容業務的小閉環來看，首先在大閉環中站得住腳，以後內容須要創做者創做，創做的導購內容被消費者觀看併產生購物行爲，創做者能夠得到佣金收入，同時平臺能夠分紅創收用來新的發展。整個鏈路能夠造成一個閉環，那麼這個業務就是靠譜的。

程序員知道這個以後有什麼用的？知道以後你就能夠跟產品經理撕逼了，同時也能夠安排需求的優先級。我關注產品規劃會，也把對接的產品經理的 KPI 要來，當他們提出很是偏離主線目標的需求就能夠直接反問這個需求對業務目標有什麼幫助來拒掉或者改掉這個需求。

在知乎這個《前端工程師的技術進階點在哪裏?》問題中我也提到了一個具體的 Case：產品的需求是在內容發佈頁面加入內容質量分的提示，但願當用戶編輯內容上傳圖片或者視頻後，能夠瞬間按照運營的質量衡量標準（好比圖片有牛皮癬扣分）計算得分並顯示出來，而且發佈時如不知足最低得分，強制彈出提示但願用戶優化後發佈，產品目標是藉此提高內容質量。

這個需求在我看來是有問題的。站在閉環角度來看，提高內容質量的關鍵是創做者的能力和創做意願，吸引創做者花大精力創做根本緣由是付出獲得的收益而不是平臺對內容質量要求的規則限制。從整個業務鏈路來看，應該在運營端突出宣傳 優質內容 = 高流量分配和高收益，在內容分發端，加強優質內容判斷和流量投放，加強內容收益的肯定性（即高質量 = 高收益） 。當創做者發現這個規則後，爲了高收益天然會專一創做高質量內容而非批量建立大量垃圾內容以量來提高命中率和轉換率。強制在發佈端以一個固定標準限制用戶發佈，能夠預見會有兩個結果：創做者內容發佈效率變低，創做成本變高，創做量減小；創做者摸透固定限制規則，經過技巧繞過來恢復本身原有的發佈頻率，按照之前的模式經過量增長算法命中率進而提高內容商品曝光帶來收益。

從技術上來看這個需求，實現也是不現實的，首先計算內容須要後端接口，對圖片和視頻的運算延遲可能達到幾十秒，根本沒法實現「秒變」，這樣創做者可能看到一個錯誤的得分，這個 Loading 的交互根本沒法設計（開過四、5 次會議討論）。再加上算法可能會有誤識別的可能，若是由於一個誤識別的邏輯致使創做的內容沒法發佈可能會讓創做者有受挫的感受。因此結合兩點我給出的建議是：首先補齊鏈路其餘節點的業務需求並跟進。對於內容質量分這個功能，第一階段做爲輔助性功能，突出功能入口並進行運營宣導，但不會做爲強制阻塞。這樣若是注重內容質量的用戶，天然會點擊按鈕使用這個功能檢測來提高內容質量。同時咱們也能夠藉此獲取數據來分析算法準確性和實際內容質量提高效果。這個過程也是培養用戶心智的過程，若是效果好第二階段所有強制開啓，也不會給用戶很大的「驚喜」。從技術和交互層面，也將複雜度從不可行，降到了點擊發送 AJAX 給後端接口，拿到結果彈個浮層展現一下的極低實現成本。因爲用戶主動觸發功能，心智上就接受了可能產生等待時間，因此運算的延遲問題也被淡化。因此最後需求和交互就修改爲這種模式。

若是你說太複雜作不了讓別人改需求和交互，別人確定不樂意去作。但從業務鏈路上作了分析，再從交互和技術實現上給出合適的方案，就更容易說服別人來作調整。 同時對本身的工做來講，也下降了工做量和技術複雜度，實現快速上線、看結果快調整的小步快跑節奏。

站在鏈路角度思考不只僅適用於業務分析

觸類旁通，不在單點而在鏈路上看問題，抓住本質，一樣能夠解決大量其餘問題。

好比以前 Angular、Vue、React 框架擁護者之間爭吵優劣和選擇的問題，其實站在前端開發這個大環來看根本不是一個問題。前端的目標和本質就是優化用戶體驗，又快又好的知足偏界面和交互的業務需求。 從這個角度來看，對於某些業務特色（例如注重 SEO 和維護成本的企業、店鋪介紹網站），jQuery 反而是最快、最佳的框架。相互攻擊或者強行爲了追趕技術而使用新技術都是走偏了，應該抓住核心點：快速響應業務需求和創造業務價值。 除了技術調研項目以外，選擇某項技術應該問本身是否熟悉這項技術，這個框架或庫是否更適合這種業務模式和團隊成員現狀，長期維護成本是什麼樣。而不是由於這個東西很火，或者看到大佬推薦或者批評。當時寫了一片文章《Angular、Vue、React 和前端的將來》有興趣的同窗能夠看看。

這種方式也很適用於推導將來發展。好比在這篇回答中《前端將來幾年的發展方向是什麼？》也是基於這種鏈路角度推導出前端將來可能的趨勢和須要繼續完善的事情。有興趣的同窗能夠看看，這裏再也不贅述。

第二年總結

2016 年 4 月到 2017 年 4 月這一年是寫代碼作工做最多的一年，尤爲是上半個財年，作了不少需求，鍛鍊了時間管理和項目管理能力，同時開始對業務理解更深入了，具有了初步的業務分析能力。在 ICE 團隊中負責業務組件、培訓等工做，站在前線接受用戶的反饋，參與設計了不少方案寫了不少組件，比較複雜的是富文本組件（基於 draft-js 封裝），後期又重構了動態表單組件，對錶單和富文本相關業務能夠說是很是瞭解了。得益於這段時間的經驗，我陸續回答了以下問題：

雖然業務結果上看起來並非特別成功，但 ICE 發展算是不錯的，自己也作了比較核心的貢獻，因此今年也拿到了很好的績效，同時在 2017 年 7 月也晉升了 P6。因爲 ICE 團隊成員艱苦奮鬥，ICE 團隊最終也得到了淘寶技術部優秀團隊（只有兩個名額），並拿到了獎金。時任 ICE 的 PM 也直接順利一年從 P6 晉升 P7。

這個時期也開始思考我的將來要作什麼，藉助貝索斯的思路，不問將來會變成什麼樣，而是問什麼東西一直沒變。 想了想人類對知識獲取和演進一直沒有中止，若是作個應用，用腦圖的形式讓人去梳理某個領域的知識，再經過內容關聯成一張大網，當一我的想要學習新知識時，能夠迅速經過知識圖譜來找到本身想要學的知識，提高了獲取知識的效率，豈不是很好。因此註冊了 ohmyknowledge.com 域名，而且學習了下 SVG 看看怎麼搞個腦圖。

但後來發現互聯網之父 Tim Berners-Lee 早在 1998 年就開始試圖建設 Semantic Web（語義網）來解決這個問題。在這個網上，互聯網就是所謂的腦圖連接，相關的概念、標準早都有了，比我所謂的想法高的不能再高了，因而就做罷了。真是你的一個想法，別人不僅是想到，極可能都作過並且失敗下線了。因此創業時要注意看看以前有沒有人作過相似事情（大機率有），跟本身的有什麼區別，成功仍是失敗了，爲何失敗了。

這一年身體也明顯感受有點差了，後期再也無法堅持工做到兩點 ，時常半夜三點肚子疼起來坐馬桶上站不起來，只能靠喝蒙脫石才能站起來（因此我揹包隨時備有蒙脫石）。最初還覺得是腸胃問題，後來公司組織的例行體檢說我前段時間可能得過急性肝炎，竟然硬扛過去了。體重也一直在上漲，16 年體檢的輕度脂肪肝也升級爲中度脂肪肝，若是再繼續嚴重就是重度和肝硬化，以後再沒法恢復。在 17 年 10 月租的房子到期以後就搬了住處，正好附近有健身房就辦了卡買了私教課，我開始試圖經過鍛鍊來恢復健康。因爲須要開車上下班，因此我也儘量減小加班時間。

除此以外，因爲將來會有移民的可能，有時項目間隙不算忙的時候，也會早起抽早上的時間刷多鄰國和英語流利說之類的但願能夠練練英語。Commit messages 也一直是用英文（Chinglish）寫的。

以上就是我在淘寶第二年的經歷和學到的東西。下週將會發布第三年的經驗，歡迎關注個人掘金帳號。

平時在知乎比較活躍，也能夠關注知乎賬號於江水和專欄於江水在知乎，以便及時接到通知。後續會開發一些項目，有興趣也能夠關注個人 GitHub。固然也能夠加我微信：Jiangshui-Yu。

此外，預計今年 5 月份，我將登錄新西蘭找工做，若是你在新西蘭或者有認識在新西蘭作開發的朋友，但願能夠聯繫我或者推薦給我，屆時或許須要請教一些問題或者幫忙內推，先謝過了。