第一日：初嘗禁果 【上帝說：“要有光！”便有了光】
萬物生靈、陽光雨露蓋源于造物之初的天工開物，我們無法想象上帝創造光明之前的世界模樣。但幸運的是，前端開發沒有神祗般的詭魅。這個技術工種 的孕育、定型、發展自有軌跡，也頗有淵源，當然，這非常容易理解。不嚴格的講，在楊致遠和費羅在斯坦福大學的機房里攛掇出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中，希望對大家有所幫助。