十日談

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

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

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

第一日：初嘗禁果

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

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

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

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

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

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

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

　　【優雅的學院派】

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

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

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

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

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

　　【規範的破與立 1】

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

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

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

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

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

　　【規範的破與立 2】

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

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

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

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

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

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

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

　　因此，勤于思考，輕裝上陣，大膽實踐，敢於創新，發掘問題所在，實打實的解決（潛在）問題，這纔是咱們真正須要的能力。放下思惟定勢枷鎖，也會有一種豁然開朗的感受。 能夠500%提升開發效率的前端UI框架！

　　第二日：科班秀才

　　【秀才仕途】

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

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

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

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

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

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

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

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

　　【半路出家】

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

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

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

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

　　第三日，幸福感

　　【先精通十行？！】

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

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

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

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

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

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

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

　　【勵志之本】

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

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

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

　　第四日，架構和僞架構

　　【代碼設計的本質】

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

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

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

　　所以，變量和類的命名纔是真正考驗架構功力的關鍵（命名是否準確清晰、單元之間是否有概念重疊或盲區），而和所謂「組合」、「繼承」、「橋接」等模式化的「外表」無本質聯繫。 能夠500%提升開發效率的前端UI框架！

　　【僞架構】

　　實際狀況是，程序員早早的就想讓本身和「架構」扯上關係，並自封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走在了技術的前沿，也所以拿到了好績效。

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