淘寶前端工程師：國內WEB前端開發十日談

一直想寫這篇「十日談」，聊聊我對Web前端開發的體會，順便解答下週圍很多人的困惑和迷惘。我不打算聊太多技術，我想，經過技術的歷練，獲得的反思應當更重要。

　　我一直認爲本身是「初級」前端開發工程師，一方面我入道尚淺，只有短短几年，另外一方面我自知對技術的鑽研並不深刻，多是因爲環境的緣由，固然最重要的是，我幸運的參與到互聯網崛起的浪潮之巔。時勢造就了一批技能薄弱但備受追捧的「弄潮者」，這在很大程度上影響咱們對「技術本質」的洞察力，多年來也一直未有成體系的「前端技術」佈道佳做，以致於當下多數人對前端技術的瞭解，蓋始於表述並不嚴謹的崗位招聘描述，而這正偏偏反映了Web前端開發對自身的模糊定位。對於不少Web前端工程師來講，初嘗禁果的快感沒法持續好久，就陷入一輪又一輪的迷惘，思索本身的職業規劃，試圖尋找到適合本身的成長道路、看清自身技能的瓶頸，尋找突破。但遺憾的是，Web前端技術被普遍接納時日尚短，沒有多少勵志的成功樣板可供遵循。然而狀況不老是這麼糟，畢竟Web前端技術是一門「技術」，和計算機科學系出同門，只是由於互聯網的高速崛起而被蒙上了迷霧，遮住了雙眼，讓咱們傻傻看不清時局。

　　那麼，如何定義Web前端技術崗位邊界?Web前端技術的價值體如今何處?前端工程師的價值僅僅體如今物以稀爲貴嗎?前端工程師的初級、中級、高級和專家之間到底如何界定?當前「我」處在什麼位置?接下來的路子應當怎樣走?何謂前端技術之「道」?我想多數人都思考過這些問題，本篇「十日談」裏的觀點可能有些偏激，但拋磚引玉，讀者權且把這些言論看成一個引子吧。

　　第一日：初嘗禁果

　　【上帝說：「要有光!」便有了光】

　　萬物生靈、陽光雨露蓋源於造物之初的天工開物，咱們沒法想象上帝創造光明以前的世界模樣。但幸運的是，前端開發沒有神祗般的詭魅。這個技術工種的孕育、定型、發展自有軌跡，也很有淵源，固然，這很是容易理解。不嚴格的講，在楊致遠和費羅在斯坦福大學的機房裏攛掇出Yahoo!時，Web前端技術就已經開始進入公衆視野，只不過當時沒有一個響亮的名字。從那時起，「基於瀏覽器端的開發」就成了軟件開發的新的分支，這也是Web前端技術的核心，即不論什麼時候何地何種系統以及怎樣的設備，但凡基於瀏覽器，都是Web前端開發的範疇(固然，這個定義很狹隘，下文會提到)。

　　在2000年以後瀏覽器技術漸漸成熟，Web產品也愈來愈豐富，中國有大批年輕人開始接觸互聯網，有一點須要注意，大部分人接觸互聯網不是始於對瀏覽器功能的好奇，而是被瀏覽器窗口內的豐富內容所吸引，咱們的思惟模式從一開始就被限制在一個小窗口以內，以致於很長時間內咱們將「視覺」認爲是一種「功能」，Web產品無非是用來展示信息之用。起初的入行者無一例外對「視覺」的關注超過了對「內容」的重視，先讓頁面看起來漂亮，去關注html/css，沿着「視覺呈現」的思路，繼續深刻下去。所以，這類人是被「視覺」所吸引，從切頁面入行，着迷於結構化的html和書寫工整的css，喜歡簡潔優雅的UI和工整的頁面設計，以後開始接觸視覺特效，並使用jQuery來實現視覺特效，以此爲線索，開始深刻研究Dom、Bom和瀏覽器的渲染機制等，html/css在這些人手中就像進攻兵器，而JavaScript則更如防守的盾牌。

　　還有另一羣人從另外一條道路接觸Web前端，即工程師轉行作前端，他們有較多的後臺語言開發背景，從讀寫數據開始，漸漸觸及瀏覽器端，接觸JavaScript庫，起初是在html代碼上加js邏輯，後來開始涉及html和css，他們喜歡OO、邏輯清晰、結構悅目的代碼，更關注界面背後的「程序語言」和數據邏輯。html/css在這些人手中則更像盾牌，而JavaScript更如進攻的兵器。

　　應當說這兩類人是互補的，他們各自了解瀏覽器本質的一部分，一撥人對渲染引擎瞭如指掌，另外一撥人則將JS引擎奉爲至寶，其實任何一部分的優點發揮出來都能作出精品。大部分前端工程師都能從這兩條淵源中找到本身的影子。但，這兩類人的思惟模式和觀點是如此不一樣，以致於造成了一些沒必要要的對抗，好比在某些公司，乾脆將Web前端技術一分爲二，「切頁面的」和「寫js的」。這樣作看上去明確了分工提升了效率，但他對員工的職業發展帶來巨大傷害。在第二日「科班秀才」中會有進一步討論。

　　我應該屬於第二類，即在學校訂兒八經的學習C/Java和C#之類，覺得大學畢業後能去作ERP軟件、桌面軟件或者進某些通訊公司寫TCP/IP相關的程序。校園招聘時選擇了中國雅虎，由於當年(08年)雅虎仍是有一點兒名氣，並且我據說雅虎比較算技術流的公司……自此就上了賊船，一發不可收拾。

　　在雅虎的這段時間，我有幸接觸到一股正氣凜然的技術流派，也造成了我對前端技術的一些基本見解，這些基本觀點一直影響我至今。

　　【優雅的學院派】

　　當年雅虎的技術流派正如日中天，擁有衆多「之父」級的高人，所營造出的Hack氛圍實在讓人陶醉的沒法自拔，那段時間我甚至寧願加班到深夜閱讀海量的文檔和源代碼，感受真的很舒服，我深深的被雅虎工程師這種低調務實、精工細琢的「服務精神」所打動，而這種不起眼的優秀品質很大程度的影響雅虎產品的用戶體驗和高質量的技術輸出。那麼，何謂「服務精神」?即你所作的東西是服務於人的，要麼是產品客戶、要麼是接手你項目的人、要麼是使用你開發的功能的人，因此技術文檔成爲伴隨代碼的標配。所以，工程師之間經過代碼就能作到心有靈犀的溝通。這是工程師的一項基本素質，即，思路清晰的完成項目，且配備了有價值的技術文檔，若是你的程序是給其餘程序員用的，則更要如此，就比如你製造一款家電都要配備說明書同樣。所以，YDN成了當時最受全球程序員最喜好的技術文檔庫，這種優雅務實的「學院氣息」讓人感受獨具魅力。

　　讓人感受奇怪的是，在中文社區始終未見這種學院派。甚至在具備先天開源優點的Web前端技術社區裏也是波瀾不驚，可見寫一篇好的技術文案真的比登天還難。我所見到的大部分所謂文檔索性把代碼裏輸出數據的語句塊拷貝粘貼出來，至於爲何數據格式要設計成這樣、若是字段有修改怎麼作、編碼解碼要求如何等等關鍵信息隻字不提，或者開發者也沒想過這些問題呢。所以，咱們一直在強調代碼的質量和可維護性，但一直以來都未見效，蓋源於缺乏這種「服務」意識的灌輸。這種意識在下文中還會屢次提到，由於它能影響你作事的每一個細節，是最應當首先突破的思想糾結。

　　除了意識問題，另外一方面是技術問題，即文筆。這也是工程師最瞧不上眼的問題，難以置信這居然是阻礙工程師突破瓶頸的關鍵所在。我已看到過數不清的人在晉升這道關卡吃了大虧，不少工程師技術實力很強，但就是表達不出來，要麼羅列一大堆信息毫無重點、要麼毫無趣味的講代碼細節，不知云云。除非你走狗屎運碰到一個懂技術的老闆，不然真的沒辦法逃脫碼農的宿命。但大部分人還振振有詞不覺得然。而在Web前端開發領域狀況更甚。前端工程師是最喜歡搞重構的，但在快節奏的需求面前，你很難用「提升了可維護性」、「提高了性能」這類虛無縹緲的詞藻爲本身爭取到時間來搞重構，說的露骨一點，可能你真的對某次重構帶來的實際價值沒法量化，只是「感受代碼更整潔了」而已。我會在下文的「僞架構」中會展開分析前端工程師的這種浮躁獻媚的技術情結。而這正是前端工程師最欠缺的素質之一：用數聽說話，用嚴謹科學的論據來支撐你的觀點，老闆不傻，有價值的東西固然會讓你去作。

　　固然，狀況不老是這麼糟糕，咱們看到中文社區中已經鍛煉出了不少寫手，他們在用高質量的文字推銷本身的技術理念，這是一個好兆頭，好的文筆是能夠鍛煉出來的。而在職場，特別是對前端工程師這個特殊職位來說，這種基本技能能夠幫你反思梳理需求的輕重緩急，從凌亂的需求中把握七寸所在。由於當你開始認真寫一封郵件的時候，這種思考已經包含其中了。

　　因此，雅虎技術的推銷是相對成功和遠播的。關鍵在於兩方面，紮實的技術功底和高超的寫手。而真正的技術大牛必定是集二者與一身，不只鑽研劍道，還能產出祕籍。這也是Yahoo!優雅的學院派氣息的動力源泉。國內不少技術團體想在這方面有所建樹，應當首先想清楚這一點。

　　【規範的破與立 1】

　　雅虎的技術運做很是規範，剛纔已經提到，包括技術、組織、文化，一切看起來有模有樣，也堪稱標杆，天然成了國內不少技術團隊和社區的效仿對象。一時間各類「規範「成風、各色「標準「大行其道，結果是質量良莠不齊。

　　咱們到底須要什麼樣的規範?雅虎的技術規範到底有何種魔力?以何種思路構建的規範纔是貨真價實的?規範有着怎樣的生命週期?想清楚這些問題，能很大程度減輕不少Web前端工程師的思想負擔，看清一部分技術本質，避免盲目跟風。

　　咱們的確須要規範，但好的規範必定是務實的，必定是「解決問題「的。好比針對項目構建的DPL能夠收納公用的視覺元件以減小重複開發、規定某OPOA項目的事件分發原則以確立增量開發的代碼慣性。反之，糟糕的規範卻顯得過於「抽象「，好比頁面性能指標、響應式設計原則。另外，儘管他山之石能夠攻玉，但拿來主義有一個大前提，就是你瞭解你的項目的關鍵問題，你要優先解決的是些關鍵問題，而外來規範正好能解決你的問題。所以規範是一本案頭手冊，是一攬子問題的解決方案，應當是「字典」，而不是「教程「。可見規範的源頭是「問題」。因此，當你想用CoffeeScript重構你的項目時、當你想引入CommonJS規範時、當你想在頁面中揉進Bootstrap時、當你打算重複造輪子搞一套JS庫時、當你想重寫一套assets打包工具時，想一想這些東東解決了你的什麼問題?會不會帶來新的問題、把事情搞複雜了?仍是爲了嚐鮮?或者爲了在簡歷中冠冕堂皇的寫上使用並精通各類新技術?

　　規範之立應當有動因，動因來源於項目需求，項目需求則來自對產品的理解和把握，這是Web前端初級工程師走向中級甚至高級的一次重要蛻變，軟件工程領域早就有「架構師」角色，而架構師每每存在於項目需求分析和概設、詳設階段。我看到的狀況是，Web前端工程師的思惟過多的限制在「界面」以內，向前和產品需求離的太遠(認爲這是視覺設計師的事)、向後和數據邏輯又隔離開來(認爲這是後臺工程師該乾的事)，所以前端規範也大都泛泛，無關項目痛癢，成了玩具。

　　雅虎技術規範的優秀之初在於它們解決問題。因此，學習使用規範應當多問一句，「他們爲何這樣作?」其實，想清楚這些問題時，腦海中天然造成了一種「遇山開山」的創造性思惟。

　　【規範的破與立 2】

　　若是說新技術的嚐鮮缺乏針對性，但至少知足程序員的某種潔癖和快感，那麼「負擔」從何而來呢?對於初學者來講，有價值學習資料可能只有這些規範，若是說規範價值不大，那又當從何入手呢?

　　剛纔我說的不是依賴於規範，而是對規範的反思，擺脫規範灌輸給咱們的思惟定勢。新人們大概是看了Wiki中的不少指標、結論、實踐，在作項目之初就附加了很多「八股式」的負擔，甚至影響咱們對項目關鍵需求和關鍵問題的洞察力和判斷力，負擔太重就沒法輕裝上陣，Wiki中提到的這些指標和規範是結論性的，是大量的實踐以後得出的，也只有經歷過大量實踐纔會真正理解這些結論，好比DomReady時間和http請求數是否有因果關係，http請求數增長是否真的會致使頁面性能降低，什麼條件下會致使性能降低?咱們從那些條文和結論中沒法找到答案。

　　舉個具體的例子，Kissy剛剛出了DPL，也是一大堆結論，好比他的佈局就採用了經典的雙飛翼，使用容器浮動來實現，那麼，這種作法就是不可撼動的「標準」嗎?看看淘寶車險首頁，佈局容器齊刷刷的inline-block，只要頂層容器去掉寬度，佈局容器自身就能根據瀏覽器寬度調整天然水平/垂直排列，輕易的適應終端寬度了。

　　再好比，淘寶旅行計劃項目中的部署方式，也沒有徹底使用Loader管理依賴，而是將依賴層級作的不多，業務邏輯使用腳原本合併，這樣就能夠更容易在build環節加入語法檢查和代碼風格檢查。

　　相似這種擺脫原有編程思惟，有針對性的用新思路新方法解決問題的作法顯然讓人感受更加清爽，編程的樂趣也正體如今打破常規的快感之中，小馬曾經說過：「製造規範是爲了打破規範」，萬不要由於這些規範標準加劇負擔，致使開始作一個簡單頁面時也顯得縮手縮腳，沒法放開身手。大膽的動手實踐，才能真正得出屬於本身的「結論 「和「標準「，纔會真正深入理解那些「結論」的意義所在。代碼寫的多了，天然熟能生巧，也容易造成成熟的技術觀點。

　　在這個過程當中，咱們惟一的對手是懶惰，惰于思考，就沒法真正發現問題，天然形不成本身的觀點。仍是那句話，任何規範、方法、結論、實踐都是爲了解決項目中的問題的，因此，咱們所接觸到那些看似「八股文」式的規範標準也是爲了解決某些問題而提出的，想清楚這些問題，理解方法論背後的「因「，心裏天然有「果」。

　　所以，「着眼當下、對症下藥」的品質就顯得彌足珍貴了，好比，雙飛翼佈局方法是爲了解決一套(html)代碼適應多種佈局設計，這裏的佈局相對於固定的產品來講也是固定的，而無針對終端的自適應(適用於移動端的榻榻米佈局彷佛尚未最佳實踐)。這是雙飛翼產生的背景，現在終端環境較之5年前已經翻天覆地，問題早已不在「多種佈局」上，而在「終端適應「上，這纔是咱們面臨的問題，須要咱們給出新的技術方案。

　　因此，勤于思考，輕裝上陣，大膽實踐，敢於創新，發掘問題所在，實打實的解決(潛在)問題，這纔是咱們真正須要的能力。放下思惟定勢枷鎖，也會有一種豁然開朗的感受。

　　第二日：科班秀才

　　【秀才仕途】

　　Web前端工程師是一個特別的崗位，只存在於互聯網領域。最近幾年隨着互聯網產業的火爆，對前端工程師的需求量暴增，兵源幾近枯竭。各大公司技術掌門必定都有過相似的苦惱：「招一個靠譜的前端工程師、難於上青天」。

　　我想，一部分緣由是，當前很多入道的前端工程師大都是轉行而來，畢竟，正兒八經的學校裏也不會教這玩意，以爲「切頁面」有啥好教的，甚至不以爲html/css是一門語言。轉行這事自沒必要詳說，你們也各自瞄準當前市場需求，形成的現象是，初級前端工程師堆成山，中高級人才卻一將難求，計算機系的科班出身就更加百裏挑一了。一方面反映了教育部門的後知後覺，另外一方面也體現了大部分人急功近利的跟風。固然最重要的緣由是，所謂中國「第一代前端工程師」並未作好佈道的工做。致使你們對於基礎和潛力的態度從以前的忽視演變爲現在的蔑視。所謂基礎，就是在大學上的那些計算機基礎課。所謂潛力，就是戒驕戒躁的務實做風。這些會在後文中屢次提到。

　　對於科班出身的莘莘學苗來講，根正苗紅自己就是一種優點，事實證實，這些人在前端技術上的成長軌跡有必定的套路，並且大都能如期的突破技能瓶頸。從一我的大學畢業到他最滿意的工做狀態，中間會通過幾個階段。

　　前2年是學習技能的階段，這個階段主要精力放在專業技能的提高上，2年內起碼要遇上平均水平，即所謂「中級「，在這個階段的人一般對軟技能不怎麼關注，溝通能力達不到平均水平，基本上是來啥活幹啥活，幹不完就加班的這種，對需求的合理性不甚理解，對項目也沒什麼把控，儘管在技能上有提升的空間，也不是公司最須要的人，但有很多成長空間。

　　工做2-3年的人在前端技能上趨於穩定，也就是技能上的第一次瓶頸，這種人幹活熟練，切頁面可能也很快，代碼看上去也比較規範，屬於熟練工，開始注重溝通技巧和一些職業技能的積累，好比帶人帶項目，至少有這方面的意識，並有過推進項目、和業務方pk需求的經歷，這就達到了中級應當具有的職業技能，但應當注意的是，這時最容易出現偏科的狀況，特別是對於那些「專門切頁面的「和「專門寫腳本的「人，畢竟html/css/js三者不分彼此，三者是一個合格前端工程師都必需要掌握的。若是你覺察到自身有偏廢的嫌疑，則要當心了，要清楚的瞭解自身的差距，並意識到瓶頸的存在，爲過渡到「中級「的打下基礎。

　　過了這道坎以後，工做3年以上的人大部分技能也趨穩，有些人對前端新技術有鑽研，可以熟練應對平常工做，軟技能也ok，具有有針對性的「拿來主義「，代碼也具備必定的架構性，開始突破「代碼民工」的這一層瓶頸，對團隊氣氛、培訓、工做環境有個性化的要求，通常來說，這種人是典型的具備潛力的「中級」工程師，但很快會遇到職業發展中的第二個技術瓶頸。

　　有少數工做3年或4年以上，在不斷尋求新的技能上的突破，最明顯的一點體現是，開始關注「底層協議」，即HTTP、第三方應用、系統對接、製造工具、工做流程等，這時思考的重點已經脫離了「切頁面」，變爲「出方案「，好比要架設一個站點，可以搭建站點框架，預見站點後續(前端)開發中的全部風險，並一一給出解決方案。項目後續開發遇到問題只要翻閱你提供的「手冊」即能找到答案。這種人是標準的「高級」Web前端工程師。

　　出方案是一件挺難的事情，它要求一個工程師同時具有經驗、技術、氣場等諸多硬技能。尤爲是對技術底子的要求很是高。

　　【半路出家】

　　那麼，轉行作前端的人又當如何呢?其實發展軌跡和科班秀才們很是相似，只是時間跨度可能會長一些，你要花更多的精力、作更多的項目、更多的反思和總結才能理解某個知識點的本質(好比HTTP協議)。固然這只是通常狀況。

　　此外，這些人還須要擺脫不少思惟定勢的禁錮。這裏我推薦你們閱讀阿當的《Web前端開發修煉之道》。固然，若是你有一個靠譜的師兄帶你入道，天然幸運萬倍。

　　但無論怎樣，我始終認爲應當秉承興趣第一的原則，無論你是誤打誤撞、仍是意欲爲之，無論你是科班秀才、仍是半路出家，興趣始終應當是第一原則，而後纔是你「想作好「。我對本身的要求沒法強加於人，因此不少業界大牛在回顧本身成功之路時，提到最多的是：「熱愛你的工做、擁抱它給你帶來的挑戰」。N.C.Zakas曾經這樣勉勵你們：

　　「我對Web開發人員最大的建議就是：熱愛你的工做。熱愛跨瀏覽器開發帶來的挑戰、熱愛互聯網技術的種種異端，熱愛業內的同行，熱愛你的工 具。互聯網發展太快了，若是你不熱愛它的話，不可能跟上它的步伐。這意味着你必須多閱讀，多動手，保證本身的才能與日俱增。下了班也不能閒着，要作一些對本身有用的 事兒。能夠參與一些開源軟件的開發，讀讀好書，看看牛人的博客。常常參加一些會議，看看別人都在幹什麼。要想讓本身快速成長，有不少事兒能夠去作，並且付出必定會有回報。」#p#副標題#e#

　　第三日，幸福感

　　【先精通十行?!】

　　興趣第一，聽上去很美，但現實卻不老是這麼酷。練就了一身本領，那也要找到對口的怪物來打一打才過癮。

　　天然，每一個人都想作出好東西，每一個工程師也都渴求這樣的機遇，用井井有條的設計、漂亮優雅的代碼、精妙的細節雕琢，作出美觀、安全、實用耐用的產品，不過現實是如此殘酷，以致於工程師們一直都缺少對產品的歸屬感。做爲前端工程師，如何才能在江湖中把握住前進方向、步步走高?畢竟，在職位繁雜的大公司，缺少人性化的工做流程影響着工程師的工做幸福感。產品從設計之初、到技術方案評審、再到實現，到處充滿了妥協，大部分產品都是雜交的產物，人與人相互掣肘，每一個人都對產品不滿意……，大躍進式的敏捷開發早就被證實百害無一利。但，或許這就是成長的代價。年輕的工程師須要更多的瞭解需求和設計、產品經理更要懂得軟件迭代規律。對於前端工程師來說更是如此，多學習交互設計和UI，多瞭解網絡協議和軟件迭代模型，更能幫助前端工程師和需求方溝通、和後臺的銜接、以及控制版本的迭代。

　　說來奇怪，前端工程師不是寫html/css/js的嗎，搞懂那些邊緣知識有什麼用?《Web前端開發修煉之道》中也提到，精通一行須要先精通十行。這裏我來解釋一下緣由。

　　做爲交互設計師的下游，前端工程師學須要習設計知識是很容易理解的，由於它能幫助你更準確的理解設計師的意圖，在原型不完整的時候也能正確的反饋設計缺陷，將問題阻擋在設計的環節，會大大減小UI bug數量，好比說，設計師會給出理想狀態下的容器樣式，卻每每忽略了文字溢出折行、長連續字符、容器寬高是否適應內容尺寸變化而變化，溢出部分是做截字仍是隱藏等諸多細節，由於設計師不懂「邊界值測試」的道理，而這些問題每每在測試階段才被發現，因此，若是能在拿到UI設計稿時就提醒設計師補充完整這些場景，天然減小測試迴歸次數。

　　另外，前端工程師必需要了解網絡協議，緣由很簡單，咱們作的產品運行在Web上。不少依賴於Ajax的實現，只有前端工程師纔會提出實現方案，產品經理不瞭解技術瓶頸，後臺工程師更不會在乎客戶端的用戶體驗，舉個簡單的例子：經過JS實現一個Ajax，若是Ajax抓取的數據源是一個302跳轉，則須要在JS程序中多作一些事情，這就須要前端工程師瞭解一些HTTP協議。應當說，這是很常見的一個場景。

　　那麼，爲何說前端工程師也要關注代碼版本控制呢?由於web開發和軟件開發本質無異，一樣具備迭代週期，需求不是一攬子提完、一口氣開發完的，是有步驟的開發，所以，每次上線開發哪些功能、爲後續擴展功能留足哪些接口、代碼在可擴展和可維護性上應看成哪些考慮……，這些應當是每一個工程師關注的事情，所謂迭代就是指這種需求的疊加，這是軟件開發的常態，也是web開發的常態，剛開始，前端工程師總會不斷抱怨沒完沒了的需求，代碼起初還算乾淨，但很快就愈來愈亂，代碼的版本管理對於Web前端工程師來講有些困難，這也使得大部分前端工程師很難上檔次，從這個角度講，前端工程師是須要向後臺工程師學習的，他們的開發量不比前端少，維護代碼的能力要超過前端工程師。另外，對於剛入行的前端工程師，心態要放對，提需求是產品經理的職責所在，整理出有價值的需求是交互設計師的職責所在，將需求做版本控制分步實現是前端工程師的職責所在，前端工程師不必去抱怨產品經理提一大堆沒規律的需求，而更應當去理解需求原因，將需求提煉成UC(用例)，讓需求在本身手中可控制。只是多數前端工程師缺少提煉、整理需求的能力，一味的在接需求，纔會搞的手忙腳亂，帶着情緒堆代碼。

　　因此，只有練就了一身本領，纔會更有目標的去尋找對產品的責任感和對團隊的歸屬感，不要誤覺得能切出漂亮的頁面就是能力的提升，純粹的寫代碼每一個人都差很少的，要成爲合格的工程師，眼界要進一步放開，前端工程師能作的，不只僅是切頁面而已，做一個精品項目，必定不乏專業的過程把控，這也是大多數人最易忽略的地方。

　　【勵志之本】

　　其實，除了我的須要明確努力的方向，每一個人都更渴望身處一個好團隊，誰都不但願有豬同樣的隊友。咱們都很羨慕處身這樣的團隊，能夠放心的將精力放在純粹的技術上，身邊每一個人都自覺的補充文檔註釋，代碼也層次清晰解偶充分重用率高，精妙的設計實現能夠更快的傳播，bug獲得的改進建議也是務實專業的，技術在這種良性互動中價值倍增。我想這也算是好團隊的一種境界了，這有賴於團隊成員水平水漲船高。不過，反觀Yahoo的成長之路，他們的技術積澱也是靠點滴的積累，其實他們當初的情況不比如今的咱們好哪去，10年的進化，才造就了Yahoo技術團隊的專業性和Hack精神，咱們每一個人纔剛剛起步而已。爲了積攢工做中的幸福感，多付出一些是值得的。

　　但我猜，你如今的處境必定不會太過樂觀，產品亂提需求、一句話的PRD、不被重視，被生硬的看成「資源「……反正，狀況就是這麼個狀況，要麼你選擇抱怨下去，要麼想辦法去改變。「積極主動「是源自心裏的一種堅韌品質，也是勵志之本，有些人在現實中被磨平了理想，有些人卻在黑暗森林中找到了方向，這就是犬儒主義和英雄氣概之間的差異。這自沒必要詳說，由於這讓我想起了「大長今」，這簡直就是前端工程師的勵志典範：「這是一個可怕的環境，足以消磨任何人的鬥志和信念，全部來這裏的人都變得麻木和無所做爲，‘多栽軒‘惡劣的環境沒有改變長今，但長今卻改變了‘多栽軒‘全部的人「。

　　若是你想作到「資深」，就必定要想清楚這一點，由於你是團隊的頂樑柱(業務)，也是幸福感的源頭(士氣)。

　　第四日，架構和僞架構

　　【代碼設計的本質】

　　讀到這裏，你不由會問，前端領域存在「架構師」嗎?這個問題會在後面的「碼農的宿命」中展開解釋。這裏先說下代碼架構的一些雜事吧。

　　什麼是架構?架構是由「架」和「構」組成，架，即元件，構，即鏈接件。所以，架構便是將整體分解爲單元，而後定義單元之間的鏈接方式。架構的含義源自禪宗，而禪宗的基本信條則之一就是真理是沒法用語言來描述的。這個基本信條有其背景，即語言具備某種抽象性。而人們對這種抽象性的悟道則直接影響對事物的見解，進而決定了對客觀世界的分解方法。

　　而在編程語言中，一樣存在這種禪宗所隱喻的悖論。在面向對象的教科書中，一般舉一些顯而易見的例子，好比「水果」是一個類，包含有蘋果、桔子、香蕉等實例，「蔬菜」也是一個類，包含白菜、冬瓜、茄子等實例。這兩個類之間並沒有交集，所以很容易理解。但實際項目中狀況要複雜的多，好比兩個圖書類目「文學」和「歷史」，那麼「明朝那些事」應當是「文學」類的實例仍是「歷史」類的實例呢?即一旦用語言說出了某一事物，即人爲的割裂了世界，因而就會陷入迷途。這在程序設計領域狀況更甚，也是形成混亂的主要根源，也就是說，若是你的程序可擴展性很差，必定是程序做者對「單元」的定義不夠準確，即單元的概念之間不夠「正交」。而這種架構終是徒有其形，根基不穩。

　　所以，變量和類的命名纔是真正考驗架構功力的關鍵(命名是否準確清晰、單元之間是否有概念重疊或盲區)，而和所謂「組合」、「繼承」、「橋接」等模式化的「外表」無本質聯繫。

　　【僞架構】

　　實際狀況是，程序員早早的就想讓本身和「架構」扯上關係，並自封xx架構師。在項目中應用各類模式分層、解耦方法，每一個項目均可以產出一套看上去很複雜的「架構圖」，感受很牛逼的樣子，沒錯，實踐這些方法論總不是壞事，但世界觀纔是方法論的基礎，只有在概念上對產品模塊有科學的定義，方法論便天然造成了，《編程珠璣》中一再說起數據結構就是靜態的算法，在Web前端領域亦是如此，在頁面的建模過程當中，定義分解維度要比分解方法更加基礎和重要。我想阿當能夠在《Web前端開發修煉之道》的第二版里加上這部份內容。

　　真正的高手用記事本就能寫出高質量的代碼、用cvs就能作到完美的版本控制、用字典式的分解就能作好系統架構，我想，這正是劍宗一派的最高境界吧。#p#副標題#e#

　　第五日：尋找突破

　　【動心忍性】

　　技術流派看上去是如此吸引人，高手就像俠客通常，來去如風瀟灑自如。但反觀本身怎麼看怎麼沒有俠客那股範兒。儘管上文提到了一些道理，瞭解這些儘管不是壞事，但缺乏實踐總感受是紙上談兵。更況且，平常的工做又是枯燥無味、繁雜單調。每一個人都盼望更高的目標、接觸新鮮技術、將新技術運用到平常，在探索嘗試之中尋找成就感。這種感受能夠理解，但卻缺乏更深層次的思考。由於越到最後越會發現一線的工做纔是最有挑戰的。固然，我說這話的前提是，你能如前文所說具有合格的軟技能，須要一些技巧讓工做變得工整有序、節奏健康，這樣你才能將注意力放在純粹的代碼中，擺脫了外界的煩擾，方能從技術的角度思考突破。這也是從初級到高級的進化過程須要大量的歷練的緣由。正如玉伯所說，「枯燥是創新的源泉。若是你發現本身沒什麼新想法，作事缺乏激情，極可能是由於你還不曾體驗過真正的枯燥的工做」。

　　關於如何尋找突破，個人建議是立刻動手作、不要等，相信本身的直覺(這裏和上文提到的先思後行是兩碼事)。好比，Slide幻燈控件理應支持觸屏事件以更好的適應移動終端，或許你在用的Slide幻燈版本很舊、或者時間不容許、再或者你懼怕對Slide改造而引入bug，不要擔憂，大不了多花業餘時間，只要想，只要感受合理和必要，就去作。由於這個過程帶來的編程體驗纔是工程師們獨有的美妙體味。我如今還時常深夜寫代碼，沒有打擾、思如泉涌、代碼也更加工整嚴謹，不失爲一種享受。所以，用眼睛去觀察，用心去感觸，「因此動心忍性，纔會增益其所不能」啊。

　　【得與失】

　　互聯網的發展的確太快，Web前端技術也在花樣翻新，有人經不起誘惑，開始作新的嘗試。前端技術雖然範圍廣，但各個分支都還比較容易入門，好比服務器端腳本編程、再好比純粹的WebApp，我認爲這二者都是前端技術的範疇，畢竟他們都沒有脫離「瀏覽器」，或者說相似瀏覽器的環境。NodeJS依賴於V8，WebApp更是軟件化的WebPage。只要打好基礎，這些方向都是值得深刻鑽研的，由於，互聯網的形態愈加多元，新的技術總能找到用武之地，這就要憑藉本身的技術嗅覺和產品直覺，尋找技術和業務的契合點。

　　這看上去是一種放棄，放棄了本身賴以生存的鐵飯碗(熟練的切頁面至少不會失業)，實則否則。這種想法是一種誤區，新的選擇並不會讓你放棄什麼，就像學會了開車，並不意味着就不會騎車了。其實改變的是思惟方式而已，是一種進步，若是你能想通這一點，你也能跟得上互聯網發展的腳步了，打開你的思惟，讓技術變成你的金剛鑽，而不是包袱。

　　因此，所謂得失之間的權衡，其實就是「解放思想」。作到了這一點，那麼你已經在作「技術驅動」了。

　　【誤區】

　　可是，不要高興的太早，「技術驅動」是須要大量的積累和經驗的。在入行初期，不少人過於着迷與此，從而陷入了迷途。好比有人糾結因而否將dt、dd的樣式清除從reset.css中拿掉，緣由是以爲這兩個標籤的清除樣式會耗費一些渲染性能;或者是否須要將for循環改成while循環以提升js執行速度。儘管這些考慮看上去是合理的，但並非性能的瓶頸所在，也就是說，你花了很大力氣重構的代碼帶來的頁面性能提高，每每還不如將兩個css文件合成一個帶來的提高明顯。就比如用一把米尺量東西，不必精確到小數點後10位，由於精確到小數點後2位就已是不許確的了。這種技術誤區經常讓人撿了芝麻丟了西瓜。

　　話說回來，這裏提到的懷疑權威的精神是絕對應當鼓勵的，但不該當止於表象，若是懷疑dt的清除樣式會對性能帶來影響，就應當想辦法拿到數據，用事實來證實本身的猜想。數據是不會騙人的。而求證過程自己就是一種能力的鍛鍊。

　　【技術驅動】

　　說到這裏，你大概對「技術驅動」有那麼一點點感受了。身邊太多人在抱怨「公司不重視前端」、公司不是技術驅動的、技術沒機會推進產品業績、個人價值得不到體現?

　　什麼是技術驅動?簡單講，就是技術對業務有積極推進做用。更多的是工程師發起、工程師影響、工程師負責。剛纔提到的用數聽說話只是一種「驅動」技巧，那麼我須要何種數據，數據從哪裏來?我來分享一個實際的場景吧。

　　工程師A被委派一個重要的頻道首頁，由於是新年版，因此要趕在年前上線。A學了一點點響應式設計，想在此次重構中加上，但誰也沒作過響應式設計，需求方根本不懂，設計師也懵懵懂懂，交互設計師太忙，作完交互稿就忙別的去了。A糾結了，循序漸進的把項目作完上線發佈，儘管不會出什麼問題，但總覺少點什麼。這時A作了兩個決定，1，我要按時完成項目，2，趁機實踐我在響應式設計中的想法和思考，若成功，做爲附加值贈送給需求方，若失敗，權當技術玩具耍一耍罷了。因此A熟練的提早完成了項目，剩下的時間開始考慮如何將首頁適應到各個平臺中，視覺設計是一大難題，他用吃飯的時間找了設計師收集建議，對窄屏中的內容模塊作了看似合理的編排，代碼上hack一下，可以正確適配，就發佈上線了。這件事情需求方不知道，視覺設計師也不瞭解，交互設計師更沒工夫操心。A感受挺爽，開始給工程師弟兄們處處炫耀這個好玩的功能，B看了問，手機端訪問量如何，A以爲這個問題有道理，就去部署埋點，一週後拿到數據出奇的意外，首先，移動段的訪問量穩步增長，趨勢健康，再者，移動端首屏焦點廣告位的點擊率較PC端高了近一倍，這個數據讓A喜出望外，興奮的拿着報表找到交互設計師C和市場研究的同事D，D看了報表以後當即啓動一個項目，專門調研公司全站響應式設計頁面在PC端和移動端的點擊率、PV、UV趨勢方面的影響……後來發生的事情就都水到渠成了，設計師C開始注意設計頁面交互時(至少是有條件的考慮)對移動端的適配，D的調研報告也放到了UED老大的案頭……接下來的事情，你懂得。A被指派要出一套響應式最佳實踐和規範，最終，A走在了技術的前沿，也所以拿到了好績效。

　　這件事情就是一個典型的技術驅動的例子。誰不讓你玩技術了，誰不重視你了，誰把你當工具了，誰以爲你的代碼沒價值?這世界只有本身把本身看扁，誰想跟你這個蠅頭小卒過不去?用實力說話，用數聽說話，用獨到的看法說話，想不作技術驅動都難。

　　第六日：碼農的宿命

　　【青春飯】

　　「碼農」是IT從業者一個自嘲的稱號，也有從事沒有發展前景的軟件開發職位，靠寫代碼爲生的意思。但我認爲碼農是一個愛稱，編碼的農民，和農民同樣有着執着純真樸實豪爽的共性，僅僅分工不一樣而已。就比如農業社會對糧食的依賴，工業化進程對計算機應用也有着很強的依賴，大量的需求催生出這樣一羣人。他們有智慧的大腦，對於編程，設計，開發都有着熟練的技巧，但多數人看來，碼農的特色是：

　　1，收入低

　　2，工做單調

　　3，工做時間長

　　實際上這個描述很是片面，或者說是外行看熱鬧。第一，全行業比較來看，軟件開發領域收入爲中等偏上;第二，程序員通常都是有癖好的，沉浸在本身的癖好中是不會感受單調的;第三，程序員有必定的時間自由度(若是你是一名合格的程序員的話)，至少不會像流水生產線工人同樣。其實，經過幾十年的發展，咱們對程序員的定義更加科學，好比不少IT企業都開始創建詳細的JM(Job Module)，即職級模型，程序員沿着專業方向能夠走到很高，甚至能夠說，程序員是能夠被當成一輩子的事業的。

　　然而，有一個很是廣泛的觀點是，程序員和作模特同樣是吃青春飯的，到了三十歲就要考慮轉行或者轉管理。儘管這種觀點頗具欺騙性，但至少它對一種人是適用的，即入錯了行的人。若是你骨子裏不想寫程序，就算年紀輕輕爲了生計寫幾年代碼，以後確定會另有他途。心非所屬則沒必要勉強，但問題是，即使如此，你知道你的心之所屬嗎?

　　咱們知道，一個成熟的產業必定須要各色崗位來支撐，若要成熟，則須要時間的沉澱，好比實體經濟製造業，創意、生產線、高級技工、技術管理四個方面都產出大量的高級人才。由於歷史悠久，咱們能看獲得。而軟件產業則否則，九成以上是剛出道的新手，並無太多「高級」和「資深」的具體樣板可供參照，在前端開發領域中狀況更甚，絕大部分人根本搞不清楚什麼樣纔是「資深」前端工程師，相比傳統軟件行業近四十年的進化，我不相信僅有幾年光景的前端技術崗位能產出多少貨真價實的「資深」。但互聯網崛起速度太快，尚未等技術基礎打牢，互聯網形態就又花樣翻新了，這種變化是一種常態，而崗位的設定也在這種變化之中天然的優勝劣汰，好比兩年前可能還不可思議數據部門會須要前端工程師，他們甚至不直接和瀏覽器打交道。前端工程師須要適應這種變化帶來的觀念衝擊，不要覺得本身只能作切頁面、或者只會給頁面搞重構、只會搞兼容性，要把本身放在整個軟件行業來看。

　　因此，因爲歷史「不悠久」致使的崗位模糊自己不是什麼大問題，崗位的演化自己就包含在互聯網的發展軌跡之中。因此，當今的互聯網IT情況，就比如移動終端的大哥大時代、雲計算的肉雞時代、或者桌面操做系統的DOS時代。所以，前端工程師當前要務是要想清楚看清楚，在互聯網中我能作什麼，而不是做爲前端工程師我能作什麼，因此，從這個角度講，技術是一個工具，放大來看，技術也只是你職業生涯中很小的組成部分，而你的從業積累、和知識面的廣度深度纔是你隨着時間的推移慢慢步入「資深」的緣由所在，而不是寫了個什麼框架就變「資深」了。若是有一天互聯網形態固定了，它的崗位可能真正就定型了，纔會有真正清晰的職能邊界，就像藍色巨人IBM中的各色崗位同樣，邊界清晰，權責分明，普通程序員只能實現接口而無機會設計接口、低層級的工程師也無機會躍進式的接觸項目架構、技術經理人也不能輕易對產品有決策性影響，到這時，人的能力才真正的被限制在方圓以內，容不得越界，這種環境下人的成長很是緩慢。根本不會有像今天互聯網亂局之中所提倡的創新、革命、成長和思想解放。簡單講，一旦產業定型，就不太須要不少「創造」了，更多的是「維護」。因此，我我的寧願互聯網IT「黑暗」的中世紀越久越好，至少對於年輕氣盛程序員來講，黑暗的叢林環境纔是真正的天然進化最理想的土壤，這時我想起了狄更斯在「雙城記」中的開篇。

　　「這是最好的時代，這是最壞的時代;這是智慧的時代，這是愚蠢的時代;這是信仰的時期，這是懷疑的時期;這是光明的季節，這是黑暗的季節;這是但願之春，這是失望之冬;人們面前有着各樣事物，人們面前一無全部;人們正在直登天堂，人們正在直下地獄」。

　　【半路出家的危與機】

　　然而，無論怎樣，信心的樹立不是一蹴而就的，對於轉行作前端的人來講更是如此。俗話說，隔行入隔山。每一個行業自有其道，天然不是想作就作。前端技術領域半路出家者很是多，咱們來分析一下轉行的心理。第一，看到前端技術入門簡單、互聯網對前端技術的需求缺口巨大;第二，前端技術所見即所得、感受學習起來很快;第三，我身邊的某某轉行做前端看上去不錯、我彷佛也能夠;第四，我不喜歡我如今作的工做、想換行業、正好前端技術上手較快，就選他吧;第五，我真的喜歡作Web前端，爲它付出再多都是值得的。

　　轉行者的心態比較容易走兩個極端，一是隻看到新行業的好，二是隻以爲原工做很糟糕。但無論是什麼行業的轉行，對本身的職業規劃的思考都應當先行一步。即務必首先清晰的回答這些問題：

　　1，我能作什麼?

　　2，我不能作什麼?

　　3，個人優點是什麼?

　　4，個人劣勢是什麼?

　　5，作新行業對我有何好處?

　　6，換行會讓我付出何種代價?

　　7，如何定義轉行成功?

　　由於面試的時候必定會被這些問題所挑戰。若是支支吾吾說不清楚，要麼是對本身將來不負責任，要麼骨子裏就是草根一族，習慣作什麼都走馬觀花淺嘗輒止，也難讓人信服你的轉行是一個權衡再三看起來合理的選擇。我沒法幫每一個人回答這些問題，但至少有兩點是肯定的，第一，Web前端技術是一個朝陽行業，絕對值得義無反顧的堅持下去;第二，你將經歷從未有過的枯燥、苛刻的歷練，所謂痛苦的「行弗亂其所爲「階段。不過話說回來，經歷太高考的人，還怕個屁啊。

　　有心之人自有城府、懂得放棄，看得清大勢中的危機、識得懂繁華里的機遇。尤爲當立足於Web前端技術時，這種感受就愈發強烈。由於國內外前端技術領域從2000年至今一直很是活躍，前端技術前進的步伐也很快，對於一些人來講，無論你是在大公司供職仍是創業，無論你是在接外包項目仍是本身寫開源項目，從轉行到跟得上新技術的腳步是有一些方法和「捷徑」的。

　　第一，梳理知識架構

　　咱們知道知識積累有兩種思路，第一種是先構建知識面、創建技術體系的大局觀，即構建樹幹，而後分別深刻每個知識點，即構建枝葉，最終造成大樹。第二種是先收集知識點，越多越好，最後用一根線索將這些知識點串接起來，一樣造成大樹。第一種方法比較適合科班秀才，第二種方法則更適合轉行做前端的人，即實踐先行，理論昇華在後。好比對「IE6怪異模式「這條線索來講，要首先將遇到的IE6下的樣式bug收集起來，每一個bug都力爭寫一個簡單的demo復現之，等到你收集到第100個bug的時候，再笨的人都能看出一些規律，這時就會天然的理解IE的hasLayout、BFC和各類bug的緣由、你就成爲了IE6的hack專家了，當你成爲100個知識線索的專家的時候，你已經能夠稱得上「資深」的水平了。咱們知道，10我的中有9個是堅持不下來的，他們會以項目忙等各類理由萬般推託，將本身硬生生的限制在草根一族，坐等被淘汰。因此，對於立志做前端的人來講，這種點滴積累和梳理知識很是重要。

　　第二，分解目標

　　將手頭的工做分解爲幾部分來看待，1，基本技能，2，項目經驗，3，溝通能力，4，主動性和影響力。想清楚作一件事情你想在哪方面獲得歷練，好比，我以前在作第一次淘寶彩票常規性重構的時候(正好是一次視覺和交互上的全新設計)，我清楚的明白此次重構的目的是鍛鍊本身在架構準富應用時的模塊解偶能力，尋找在其餘項目中架構的共通之處，因此我寧願加班或花更多精力作這個事情，固然更沒打算向業務方多解釋什麼，這件事情對我來講純粹是技能的鍛鍊。而通過這一次重構以後，我意外的發現對業務的理解更透徹深刻、更清晰的把握用戶體驗上的瓶頸所在。若是一開始就把此次常規改版當成一個普通的項目循序漸進的作，我只能說，你也能按時完成項目，按時發佈，但真真浪費了一次寶貴的鍛鍊機會，項目總結時也難有「動心忍性」的體會。

　　因此，每一個項目的每一個事情都應當認真對待，甚至要超出認真的對待，想清楚作好每件事對於本身哪方面有所提高?哪怕是一個bug的解決，即使不是本身的問題也不要草草踢出去了事，而是分析出問題緣由，給出方案，有目的involve各方知曉……，正規的對待每一個不起眼的小事，時間久了歷練了心智，這時若是忽然遇到一個p0級的嚴重線上bug(好比淘寶首頁白屏，夠嚴重的了吧)也不會當即亂了方寸，這也是我上文提到的心有城府天然淡定萬倍，而這種淡定的氣場對身邊浮躁的人來講也是一種震懾和療傷，影響力天然而然就造成了。

　　第三，做分享

　　作分享這事兒真的是一本萬利。有心的人必定要逼着本身作分享，並且要作好。首先，本身瞭解的知識不叫掌握，只有理解並表達出來能讓別人理解才叫掌握，好比若是你解釋不清楚hasLayout，多半說明本身沒理解，若是你搞不懂雙飛翼的使用場景，可能真的不知道佈局的核心要素。再者，做分享絕對鍛鍊知識點的提煉能力和表達能力，咱們做爲工程師不知道多少次和強硬的需求方pk，被擊敗的一塌糊塗。也反映出工程師很難提煉出通俗易懂的語言將技術要點表述清楚。而作ppt和分享正是鍛鍊這種能力，將本身的觀點提煉出要點和線索，分享次數多了，天然熟能生巧。檔次也再慢慢提升。另外一方面，逼迫本身站在公衆場合裏大聲講話，原本就是提升自信的一種鍛鍊。

　　這時，你或許會問，我講的東西你們都明白，我講的是否是多餘，我第一次講講很差怎麼辦，你們會不會像看玩猴似的看我「這SB，講這麼爛還上來說」?要是講很差我之後再講沒人聽怎麼辦，我從此怎麼作人啊?

　　老實說，這是一道坎，任何人都要跨過去的，誰都同樣，你敢鼓起勇氣在大庭廣衆之下向愛人表白，就沒勇氣對本身的職業宿命說不?其實勇敢的跨越這一步，你會意外的收穫他人的掌聲和讚許，這些掌聲和讚許不是送給你所分享的內容，而是送給你的認真和勇氣。這個心結過不去，那就老老實實呆在本身的象牙塔裏遺老終生，當一生工程師裏的鑽石王老五吧。

　　【匠人多福】

　　若是你能耐心讀到這裏，內心必定有一個疑問，上面說的都是技術上能力上怎樣怎樣，那我所作項目不給力又當如何?若是項目不掙錢、黃了、裁了，個人努力不就白費了嗎?我又有什麼績效和價值呢?

　　沒錯，有這種想法的人不在少數。特別是剛出道的校招同窗每每更加心高氣傲，覺得本身有改變世界的本事，必定要參與一個牛逼的團隊作一款光鮮靚麗受人追捧能給本身臉上貼金的項目。若是你有這種想法，趁早打消掉這個念頭，固然，咱們這裏先不討論創業的情形。

　　第一，若是你剛畢業就加入一個牛逼團隊，說難聽點，你就是團隊中其餘人眼中的「豬同樣的隊友」，不創造價值且拖項目後腿(顯然你們都要照顧你的成長啊)，按照271理論，你沒有理由不是這個1。至少至關長一段時間內是這樣。

　　第二，你在所謂牛逼團隊中的創造性受限，由於創新多來自於團隊中的「資深「和大牛們，你參與討論但觀點一般不會被採納，他們只會給你這個菜鳥分活幹，想一想看，你如何能花兩到三年就超越身邊的大牛們?甚至連拉近與他們的距離都難。

　　第三，若是身在牛逼團隊，天然心理對周圍的牛人們有所期待，但願他們能灌輸給你一些牛逼的知識和牛逼的理念。這種思想上的惰性在職場生涯之初是很是危險的。要知道技術和知識自己是很簡單和淳樸的，只不過披上了一個光鮮項目的外衣而讓人感受不同凡響。

　　第四，由簡入奢易，由奢入簡難，作過一個看似光彩的項目，心理再難放平穩，去踏實的作一個看上去不那麼酷的產品。這種浮躁心態會嚴重影響從此的職業發展和成長。

　　第五，光鮮靚麗的項目被各類老大關注，是難容忍犯錯誤的，傻瓜都知道犯錯誤在成長之初的重要性。

　　就我所看到的情形看，一開始加入看似很牛的項目組，三年後獲得的成長，比那些開始加入一個不被重視的項目的同窗要小不少，然後者在能力上的彈性卻更大。因此，道理很簡單，你是要把一個很酷的項目作的和以前差很少酷，仍是把一個不酷的項目作的很酷?項目是否是由於你的加入而變得不同凡響了?

　　從這個角度講，無論是轉行的新人仍是剛出道的秀才，最好將本身看成「匠人」來對待，你的工做是「打磨」你的項目，並在這個過程當中收穫經驗和成長。付出的是勤奮，鍛鍊的是手藝，磨練的是心智。所以，你的價值來自於你「活兒「的質量，「活兒」的質量來自於你接手的項目以前和以後的差異。作好活兒是匠人應有的職業心態。想通這一點，心裏天然少一些糾結，纔會對本身對項目的貢獻度有客觀的認識，不會感受被項目所綁架。

　　作一名多福的匠人，擁有了金剛鑽、就不怕攬不到瓷器活兒。但對於人的成長來講，若是說「項目」重要但不關鍵，那麼什麼纔是關鍵呢?這個話題還會在接下來的「伯樂與千里馬」這篇中給出答案。

　　【若干年後】

　　如今，讓咱們回過頭回答一下「青春飯」的問題。在「青春飯」小節中提到，「程序員到三十歲以後須要轉行或者轉管理嗎?」

　　上文提到，工業化生產的四個領域，1，創意，2，生產線，3，高級技工，4，技術管理。Web前端技術也是如此，能夠在這四個領域找到各自的歸宿。

　　第一，「創意「

　　即和產品需求越走越近，擁有良好的產品感，對產品需求、設計交互把握準確，可以用適當的技術方案推進產品用戶體驗，屬於「架構師」的範疇，由於職能更加靠前，偏「出主意」型的。這種人更貼近用戶，須要活躍的思惟、廣闊眼界、厚實的項目經驗。更多的影響產品體驗方面的決策。

　　第二，「生產線「

　　即前端基礎設施建設，優化前端開發流程，開發工具，包括開發環境、打包上線自動化、和各類監控平臺和數據收集等，屬於「技術支持」的範疇，相比於不少企業粗獷難用的平臺工具，前端技術方面的基礎設施建設基礎還需更加夯實，由於這是高效生產的基本保證。

　　第三，「高級技工「

　　即高級前端開發工程師，專職作項目，將產品作精作透，用代碼將產品用戶體驗推向極致，偏「實戰」型的，是項目的中堅力量，直接產出成果，影響產品效益。屬於項目裏的「資深」。

　　第四，「技術管理「

　　即作技術經理，這纔是多數人所理解的「管理」，其實就是帶團隊、靠團隊拿成果。這類人具備敏感的技術情結，在技術風潮中把握方向，可以指導培訓新人，爲各個業務輸出前端人才，偏「教練」型的，促進新技術對業務的影響。並有意識的開闢新的技術領域。

　　可見，轉管理可不是想固然，也不是所謂作項目變資深了就能轉管理，轉了也不必定能作好。根據「彼得原理」，即人老是傾向於晉升到他所不能勝任的崗位，這時就又陷入「帕金森」定律所隱喻的惡性循環之中，直到你帶的團隊整個垮掉。

　　因此，轉管理應當是一件很是慎重的事情，不是所謂程序員混不下去就轉管理這麼簡單。但無論怎樣，有一件事情是須要尤爲要想清楚，即，轉了管理，技術就丟了嗎?咱們在第七日「伯樂與千里馬」中再深刻聊聊這個事兒。#p#副標題#e#

　　第七日，伯樂與千里馬

　　【師兄們的抉擇 1】

　　千里馬常有，而伯樂不常有。——韓愈，「馬說」。

　　一我的這輩子能遇到一個好師兄是一種緣分，可遇不可求。不少人工做中的幸福感彷佛也源自這種被認同，被師兄的瞭解和認同，有人能直言不諱的指出你的不足，幫你發現機會，並將最適合你作的事情分配給你，這是莫大的幸運，但如此幸運的人十之一二，大多數人由於缺乏伯樂的提點，漸漸辱於「奴隸人之手「，潛力漸失，毀於中庸。

　　在前端技術領域，這種狀況很廣泛也很特殊，固然有不少客觀緣由。即前端技術進入公衆視野時間不長，有實力的伯樂更加是百裏挑一。更況且，Web前端技術還有着一些江湖氣，知識點過於瑣碎，技術價值觀的博弈也難分伯仲，即全局的系統的知識結構並未成體系，這些因素也客觀上影響了「正統「前端技術的沉澱，奇技淫巧被濫用，前端技術知識的傳承也過於泛泛，新人很難看清時局把握主次，加之業務上的壓力，未免過早致使技術動做變形。而這些問題也沒法全賴本身全盤消化，如有人指點迷津，狀況要好上萬倍。所以，前端技術領域，爲本身覓得一個靠譜的師兄，重要性要蓋過項目、團隊、公司、甚至薪水。

　　這也是上文所說的「項目不重要，師兄才重要「的緣由。說到這裏就有一個問題，每一個人都問下本身，你是想當師弟呢仍是想當師兄呢?當師兄有什麼好處呢?

　　沒錯，不少師兄都是被師兄，甚至沒有作好當師兄的準備，更進一步說，很多經理人也都是「被經理人「，沒有作好準備就被推到了管理崗位。帶人是耗精力的，師兄要作不少思想鬥爭才捨得把這些寶貴的精力放在那些菜鳥身上，這不是一個技術問題，而是一個道德問題。要記住，沒有誰應該平白無故把本身所掌握技能給你傾囊相授，如此皆命也。讀到這裏，做爲菜鳥，做爲學徒，做爲新人，做爲師弟，你作到對這份命運的足夠尊重了嗎?

　　尊師重教的傳統美德並無在技術領域得以很好的延續。也正由於此，人才梯隊難創建起來，但對於師兄來講，倒是有更多機遇的。

　　【師兄們的抉擇 2】

　　做爲師兄，無論是主動仍是被動，確定會想當師兄對我有什麼提高?對於初次作師兄的人來講，最大的提高在於兩方面，1，任務分解，2，問題分析。

　　第一，任務分解，做爲師兄要給師弟派分任務，就涉及到任務分解，分解這事兒往低了說，就是派活，往高了說，其實就是作「架構」，好比一個頁面，按照什麼思路進行模塊劃分，模塊劃分是否適合單人開發，如何控制共用樣式和共用腳本，我須要爲他提供什麼接口，如何控制他的代碼併入整個頁面時不會影響總體頁面代碼的熵值，這些都是實打實的「架構「應該包含的問題，而從小頁面開始就作這種鍛鍊，作的多了，「架構感」天然就造成了。

　　第二，問題分析，在以前本身寫代碼都是單打獨鬥，什麼都是用代碼解決問題，但一旦涉及協做，就要強迫本身分析問題，或者說給徒弟分析問題，告訴他應當用什麼方法來解決問題，當說到「方法」時，腦子裏定造成了一個方案，按照這個方案路子走必定能解決問題。分析問題比寫代碼要更抽象、更高效，由於在腦子裏構建方案要比寫代碼要快，思考也會更加縝密，當鍛鍊的多了，思考愈來愈快，代碼的草稿也很快就在腦海中造成了，這也是咱們說爲何不少人不寫代碼但編碼思路和水平都很高的緣由。

　　這些工做方法對了，積累多了，就是提升。對於技術經理人來講，也是一樣的道理。因此，就像在第五日的「得與失」部分提到的那樣，轉身師兄、變身管理並不意味着「失「掉技術飯碗，而是一種進步。

　　【作本身的伯樂】

　　那麼，在前端技術領域裏什麼樣的人才算千里馬，其實人人都是千里馬，人人均可以發掘本身的潛力，若是上面的文字你能讀懂，能承認，這種自我發掘已經開始了，沒有一個好伯樂又何妨呢?作一個勤快的小碼農，少一些勢利的紛爭，很快會發現，本身才是最好的伯樂。

　　但這並非說，他人對本身的觀點不重要，有時甚至要綜合各類聲音，因此，多找身邊的大牛們聊聊天，多找你的師兄和主管，無論他們給你的建議是多麼形而上，總有一些聲音對你是有益的，多收集，有好處。

　　第八日，作地球上最牛的UED

　　【誰推進了歷史前進，英雄?仍是人民?】

　　「作地球上最牛的UED!」，這是淘寶UED創立之初的口號，如今被漸漸淡忘了，由於微博上的一些討論，又想起了這份曾經美好的初衷。玉伯也感嘆道：「這願景曾吸引了多少好漢前往投奔呀。只惋惜短短几年間，這願景好像愈來愈遠了」。問題是，要作好一個團隊，靠的是我的、仍是總體?願景是愈來愈遠了嗎?

　　是誰推進了歷史的前進，是英雄?仍是人民?微觀來看，是英雄，宏觀來看，是人民。再放大了看，是互聯網大潮之崛起推進了前端技術的進步，時勢須要UED、須要用戶體驗。

　　因此，UED團隊的創立發展受這些積極的外因影響，遇上了好時候，成員也跟着沾光。然而，我並不關心這個口號，我只關心體制內的關鍵人物，那些帶動整個團隊水漲船高的人們。每每咱們發現，某些人的高度表明瞭整個團隊的高度，個體的影響力表明了整個團隊的影響力，某我的的水平表明瞭整個團隊的水平。支付寶、淘寶、騰訊、百度、盛大，都是如此。而咱們做爲普通的個體，正是要勵志成爲這種人，成爲真真用技術推進用戶體驗前進的尖刀人物。

　　這時我想起了不少人在知乎上的問題，關於跳槽、關於轉行、關於創業、關於各類UED團隊。我想，讀得懂我上面的文字，你心理也許會有本身的答案。

　　【歸宿】

　　最後，還有一個不得不說的問題，即歸屬問題，前端開發應當歸屬於UED仍是技術部門?應當說，當前Web前端技術的價值體如今「用戶體驗「上。是用戶體驗這塊陣地最後一道坎。也就是說，前端工程師應當重點考慮我所做的頁面的感官體驗。這是須要一些靈感和感性的，應當看到帥氣優雅的界面會心有所動、或者實現一款精巧的小組件時萌生一陣快意。這種所見即所得的美妙編程體驗正是其餘後端工程師沒法體驗到的。所以，這種精確到像素級的精工雕琢雖然不直接決定產品生死，但倒是提高產品品味和時尚感的要素。物質愈來愈豐富的今天，大衆的更高訴求不就是品味和時尚嗎?

　　若是將前端歸到技術部門，一方面和「設計「離的更遠，代碼寫的規規矩矩但漸缺乏了靈性，另外一方面做爲工程師又缺乏計算機專業課的功底，才真正喪失了優點所在，若是有一天，前端工程師的平均水平足夠高，清一色的計算機科班出身，彷佛更合適納入到技術部門。因此，Web前端工程師是「工程師「，須要科學嚴謹的編程能力，但身處UED所應當具有的美感和靈性是萬不可被剝奪去的。

　　還有一點，Web前端工程師做爲UED之中最具實踐精神和邏輯思惟的工種，是可以將技術對設計的影響發揮到最大，能夠催生出大量的創造和革新的，這一點也是傳統後端工程師所不具有的。#p#副標題#e#

　　第九日，前端技術體系

　　如今愈來愈感受到前端技術須要成體系的積累，一方面能夠規範咱們的前端技術培訓，另外一方面，做爲知識線索爲新人作指引，省的走彎路，避免陷入奇技淫巧的深坑之中不能自拔。

　　以前我整理了一下「前端技術知識結構」，羅列的比較散，但也基本表述清楚了個人觀點。今年上半年也在整個研發中心組織了一次前端技術培訓，對於前端技術的演化規律也有過整理，都放在了這個ppt中，但願對你們有所幫助。

　　概觀國內前端技術界，其實我不認爲和國外頂尖的前端技術有多少年差異，甚至不少方面都走在了他們前面，好比對IE6暴力式的兼容，以及各類外殼瀏覽器的風靡(呵呵，開玩笑哈)。惟一的美中不足是國外頂尖的前端技術很難第一時間就在國內普及，多是兩方面緣由，一是多數人英文底子不好，這但是個大問題啊。二是國內前端技術方面高質量的譯文圖書實在是少的可憐。那麼……

　　接下來的最後一日，想了想仍是留給答疑吧，一方面不少人讀到這裏確定滿肚子問題，我收集下，爭取及時回覆你們。另外一方面，萬一上面的話的有得罪人的地方，還好留有餘地來補救，哈哈。

　　ps：一直很喜歡「神曲」的插圖，從「天堂篇」裏摘出一張做爲封面吧，呵呵。

　　第十日：QA

　　--EOF --