Web前端初級工程師走向中級甚至高級的一次重要蛻變

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


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


　　雅虎技術規範的優秀之初在於它們解決問題。所以，學習使用規範應當多問一句，“他們爲什麼這樣做?”其實，想清楚這些問題時，腦海中自然形成了一種“遇山開山”的創造性思維。