一直想寫這篇“十日談”，聊聊我對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開發人員最大的建議就是：熱愛你的工作。熱愛跨瀏覽器開發帶來的挑戰、熱愛網際網路技術的種種異端，熱愛業內的同行，熱愛你的工 具。網際網路發展太快了，如果你不熱愛它的話，不可能跟上它的步伐。這意味著你必須多閱讀，多動手，保證自己的才能與日俱增。下了班也不能閒著，要做一些對自己有用的 事兒。可以參與一些開源軟體的開發，讀讀好書，看看牛人的部落格。經常參加一些會議，看看別人都在幹什麼。要想讓自己快速成長，有很多事兒可以去做，而且付出一定會有回報。“
第三日，幸福感
【先精通十行？！】
興趣第一，聽上去很美，但現實卻不總是這麼酷。練就了一身本領，那也要找到對口的怪物來打一打才過癮。
自然，每個人都想做出好東西，每個工程師也都渴求這樣的機遇，用層次分明的設計、漂亮優雅的程式碼、精妙的細節雕琢，做出美觀、安全、實用耐用的產品，不過現實是如此殘酷，以至於工程師們一直都缺乏對產品的歸屬感。作為前端工程師，如何才能在江湖中把握住前進方向、步步走高？畢竟，在職位繁雜的大公司，缺乏人性化的工作流程影響著工程師的工作倖福感。產品從設計之初、到技術方案評審、再到實現，處處充滿了妥協，大部分產品都是雜交的產物，人與人相互掣肘，每個人都對產品不滿意……，大躍進式的敏捷開發早就被證明百害無一利。但，或許這就是成長的代價。年輕的工程師需要更多的瞭解需求和設計、產品經理更要懂得軟體迭代規律。對於前端工程師來講更是如此，多學習互動設計和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就能做到完美的版本控制、用字典式的分解就能做好系統架構，我想，這正是劍宗一派的最高境界吧。
第五日：尋找突破
【動心忍性】
技術流派看上去是如此吸引人，高手就像俠客一般，來去如風瀟灑自如。但反觀自己怎麼看怎麼沒有俠客那股範兒。儘管上文提到了一些道理，瞭解這些儘管不是壞事，但缺少實踐總感覺是紙上談兵。更何況，日常的工作又是枯燥無味、繁雜單調。每個人都盼望更高的目標、接觸新鮮技術、將新技術運用到日常，在探索嘗試之中尋找成就感。這種感覺可以理解，但卻缺少更深層次的思考。因為越到最後越會發現一線的工作才是最有挑戰的。當然，我說這話的前提是，你能如前文所說具備合格的軟技能，需要一些技巧讓工作變得工整有序、節奏健康，這樣你才能將注意力放在純粹的程式碼中，擺脫了外界的煩擾，方能從技術的角度思考突破。這也是從初級到高階的進化過程需要大量的歷練的原因。正如玉伯所說，“枯燥是創新的源泉。如果你發現自己沒什麼新想法，做事缺少激情，很可能是因為你還未曾體驗過真正的枯燥的工作”。
關於如何尋找突破，我的建議是馬上動手做、不要等，相信自己的直覺（這裡和上文提到的先思後行是兩碼事）。比如，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前端技術也是如此，可以在這四個領域找到各自的歸宿。
第一，“創意“
即和產品需求越走越近，擁有良好的產品感，對產品需求、設計互動把握準確，能夠用適當的技術方案推動產品使用者體驗，屬於“架構師”的範疇，因為職能更加靠前，偏“出主意”型的。這種人更貼近使用者，需要活躍的思維、廣闊眼界、厚實的專案經驗。更多的影響產品體驗方面的決策。
第二，“生產線“
即前端基礎設施建設，優化前端開發流程，開發工具，包括開發環境、打包上線自動化、和各種監控平臺和資料收集等，屬於“技術支援”的範疇，相比於很多企業粗獷難用的平臺工具，前端技術方面的基礎設施建設基礎還需更加夯實，因為這是高效生產的基本保證。
第三，“高階技工“
即高階前端開發工程師，專職做專案，將產品做精做透，用程式碼將產品使用者體驗推向極致，偏“實戰”型的，是專案的中堅力量，直接產出成果，影響產品效益。屬於專案裡的“資深”。
第四，“技術管理“
即做技術經理，這才是多數人所理解的“管理”，其實就是帶團隊、靠團隊拿成果。這類人具有敏感的技術情結，在技術風潮中把握方向，能夠指導培訓新人，為各個業務輸出前端人才，偏“教練”型的，促進新技術對業務的影響。並有意識的開闢新的技術領域。
可見，轉管理可不是想當然，也不是所謂做專案變資深了就能轉管理，轉了也不一定能做好。根據“彼得原理”，即人總是傾向於晉升到他所不能勝任的崗位，這時就又陷入“帕金森”定律所隱喻的惡性迴圈之中，直到你帶的團隊整個垮掉。
所以，轉管理應當是一件非常慎重的事情，不是所謂程式設計師混不下去就轉管理這麼簡單。但不管怎樣，有一件事情是需要尤其要想清楚，即，轉了管理，技術就丟了嗎？我們在第七日“伯樂與千里馬”中再深入聊聊這個事兒。
第七日，伯樂與千里馬
【師兄們的抉擇 1】
千里馬常有，而伯樂不常有。——韓愈，“馬說”。
一個人這輩子能遇到一個好師兄是一種緣分，可遇不可求。很多人工作中的幸福感似乎也源自這種被認同，被師兄的瞭解和認同，有人能直言不諱的指出你的不足，幫你發現機會，並將最適合你做的事情分配給你，這是莫大的幸運，但如此幸運的人十之一二，大多數人因為缺少伯樂的提點，漸漸辱於“奴隸人之手“，潛力漸失，毀於中庸。
在前端技術領域，這種情況很普遍也很特殊，當然有很多客觀原因。即前端技術進入公眾視野時間不長，有實力的伯樂更加是鳳毛麟角。更何況，Web前端技術還有著一些江湖氣，知識點過於瑣碎，技術價值觀的博弈也難分伯仲，即全域性的系統的知識結構並未成體系，這些因素也客觀上影響了“正統“前端技術的沉澱，奇技淫巧被濫用，前端技術知識的傳承也過於泛泛，新人難看清時局把握主次，加之業務上的壓力，未免過早導致技術動作變形。而這些問題也無法全賴自己全盤消化，若有人指點迷津，情況要好上萬倍。因此，前端技術領域，為自己覓得一個靠譜的師兄，重要性要蓋過專案、團隊、公司、甚至薪水。
這也是上文所說的“專案不重要，師兄才重要“的原因。說到這裡就有一個問題，每個人都問下自己，你是想當師弟呢還是想當師兄呢？當師兄有什麼好處呢？
沒錯，很多師兄都是被師兄，甚至沒有做好當師兄的準備，更進一步說，不少經理人也都是“被經理人“，沒有做好準備就被推到了管理崗位。帶人是耗精力的，師兄要做很多思想鬥爭才捨得把這些寶貴的精力放在那些菜鳥身上，這不是一個技術問題，而是一個道德問題。要記住，沒有誰應該無緣無故把自己所掌握技能給你傾囊相授，如此皆命也。讀到這裡，作為菜鳥，作為學徒，作為新人，作為師弟，你做到對這份命運的足夠尊重了嗎？
尊師重教的傳統美德並沒有在技術領域得以很好的延續。也正因為此，人才梯隊難建立起來，但對於師兄來說，卻是有更多機遇的。
【師兄們的抉擇 2】
作為師兄，不管是主動還是被動，肯定會想當師兄對我有什麼提升？對於初次做師兄的人來說，最大的提升在於兩方面，1，任務分解，2，問題分析。
第一，任務分解，作為師兄要給師弟派分任務，就涉及到任務分解，分解這事兒往低了說，就是派活，往高了說，其實就是做“架構”，比如一個頁面，按照什麼思路進行模組劃分，模組劃分是否適合單人開發，如何控制共用樣式和共用指令碼，我需要為他提供什麼介面，如何控制他的程式碼併入整個頁面時不會影響整體頁面程式碼的熵值，這些都是實打實的“架構“應該包含的問題，而從小頁面開始就做這種鍛鍊，做的多了，“架構感”自然就形成了。
第二，問題分析，在之前自己寫程式碼都是單打獨鬥，什麼都是用程式碼解決問題，但一旦涉及協作，就要強迫自己分析問題，或者說給徒弟分析問題，告訴他應當用什麼方法來解決問題，當說到“方法”時，腦子裡定形成了一個方案，按照這個方案路子走一定能解決問題。分析問題比寫程式碼要更抽象、更高效，因為在腦子裡構建方案要比寫程式碼要快，思考也會更加縝密，當鍛鍊的多了，思考越來越快，程式碼的草稿也很快就在腦海中形成了，這也是我們說為什麼很多人不寫程式碼但編碼思路和水平都很高的原因。
這些工作方法對了，積累多了，就是提高。對於技術經理人來說，也是同樣的道理。所以，就像在第五日的“得與失”部分提到的那樣，轉身師兄、變身管理並不意味著“失“掉技術飯碗，而是一種進步。
【做自己的伯樂】
那麼，在前端技術領域裡什麼樣的人才算千里馬，其實人人都是千里馬，人人都可以發掘自己的潛力，如果上面的文字你能讀懂，能認可，這種自我發掘已經開始了，沒有一個好伯樂又何妨呢？做一個勤快的小碼農，少一些勢利的紛爭，很快會發現，自己才是最好的伯樂。
但這並不是說，他人對自己的觀點不重要，有時甚至要綜合各種聲音，所以，多找身邊的大牛們聊聊天，多找你的師兄和主管，不管他們給你的建議是多麼形而上，總有一些聲音對你是有益的，多收集，有好處。
第八日，做地球上最牛的UED
【誰推動了歷史前進，英雄？還是人民？】
“做地球上最牛的UED！”，這是淘寶UED創立之初的口號，現在被漸漸淡忘了，因為微博上的一些討論，又想起了這份曾經美好的初衷。玉伯也感嘆道：“這願景曾吸引了多少好漢前往投奔呀。只可惜短短几年間，這願景好像越來越遠了”。問題是，要做好一個團隊，靠的是個人、還是整體？願景是越來越遠了嗎？
是誰推動了歷史的前進，是英雄？還是人民？微觀來看，是英雄，巨集觀來看，是人民。再放大了看，是網際網路大潮之崛起推動了前端技術的進步，時勢需要UED、需要使用者體驗。
所以，UED團隊的創立發展受這些積極的外因影響，趕上了好時候，成員也跟著沾光。然而，我並不關心這個口號，我只關心體制內的關鍵人物，那些帶動整個團隊水漲船高的人們。往往我們發現，某些人的高度代表了整個團隊的高度，個體的影響力代表了整個團隊的影響力，某個人的水平代表了整個團隊的水平。支付寶、淘寶、騰訊、百度、盛大，都是如此。而我們作為普通的個體，正是要勵志成為這種人，成為真真用技術推動使用者體驗前進的尖刀人物。
這時我想起了很多人在知乎上的問題，關於跳槽、關於轉行、關於創業、關於各種UED團隊。我想，讀得懂我上面的文字，你心理也許會有自己的答案。
【歸宿】
最後，還有一個不得不說的問題，即歸屬問題，前端開發應當歸屬於UED還是技術部門？應當說，當前Web前端技術的價值體現在“使用者體驗“上。是使用者體驗這塊陣地最後一道坎。也就是說，前端工程師應當重點考慮我所作的頁面的感官體驗。這是需要一些靈感和感性的，應當看到帥氣優雅的介面會心有所動、或者實現一款精巧的小元件時萌生一陣快意。這種所見即所得的美妙程式設計體驗正是其他後端工程師無法體驗到的。因此，這種精確到畫素級的精工雕琢雖然不直接決定產品生死，但卻是提升產品品味和時尚感的要素。物質越來越豐富的今天，大眾的更高訴求不就是品味和時尚嗎？
如果將前端歸到技術部門，一方面和“設計“離的更遠，程式碼寫的規規矩矩但漸缺少了靈性，另一方面作為工程師又缺少計算機專業課的功底，才真正喪失了優勢所在，如果有一天，前端工程師的平均水平足夠高，清一色的計算機科班出身，似乎更合適歸入到技術部門。所以，Web前端工程師是“工程師“，需要科學嚴謹的程式設計能力，但身處UED所應當具備的美感和靈性是萬不可被剝奪去的。
還有一點，Web前端工程師作為UED之中最具實踐精神和邏輯思維的工種，是能夠將技術對設計的影響發揮到最大，可以催生出大量的創造和革新的，這一點也是傳統後端工程師所不具備的。
第九日，前端技術體系
現在越來越感覺到前端技術需要成體系的積累，一方面可以規範我們的前端技術培訓，另一方面，作為知識線索為新人做指引，省的走彎路，避免陷入奇技淫巧的深坑之中不能自拔。
之前我整理了一下“前端技術知識結構”，羅列的比較散，但也基本表述清楚了我的觀點。今年上半年也在整個研發中心組織了一次前端技術培訓，對於前端技術的演化規律也有過整理，都放在了這個ppt中，希望對大家有所幫助。
概觀國內前端技術界，其實我不認為和國外頂尖的前端技術有多少年差別，甚至很多方面都走在了他們前面，比如對IE6暴力式的相容，以及各種外殼瀏覽器的風靡（呵呵，開玩笑哈）。唯一的美中不足是國外頂尖的前端技術難第一時間就在國內普及，可能是兩方面原因，一是多數人英文底子很差，這可是個大問題啊。二是國內前端技術方面高質量的譯文圖書實在是少的可憐。那麼……
接下來的最後一日，想了想還是留給答疑吧，一方面很多人讀到這裡肯定滿肚子問題，我收集下，爭取及時回覆大家。另一方面，萬一上面的話的有得罪人的地方，還好留有餘地來補救，哈哈。
ps：一直很喜歡“神曲”的插圖，從“天堂篇”裡摘出一張作為封面吧，呵呵。
第十日：QA
–EOF —