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年前已經翻天覆地，問題早已不在「多種佈局」上，而在「終端適應「上，這纔是咱們面臨的問題，須要咱們給出新的技術方案。

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