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項目的事件分發原則以確立增量開發的代碼慣性。反之，糟糕的規范卻顯得過於“抽象“，比如頁面性能指標、響應式設計原則。另外，盡管他山之石可以攻玉，但拿來主義有一個大前提，就是你了解你的項目的關鍵問題，你要優先解決的是些關