# 摘抄 # 規範的破與立

 

規範的破與立 1

雅虎的技術運做很是規範，包括技術、組織、文化，一切看起來有模有樣，堪稱標杆，天然成了國內不少技術團隊和社區的效仿對象。一時間各類「規範「成風、各色「標準「大行其道，瞬間氾濫成災。

咱們到底須要什麼樣的規範？雅虎的技術規範到底有何種魔力？什麼規範纔有價值？規範有着怎樣的生命週期？想清楚這些問題，能很大程度減輕Web前端工程師的思想負擔，避免盲目跟風。

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

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

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

規範的破與立 2

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

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

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

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

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

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

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

 

出處：

《十日談，第一日：初嘗禁果》https://github.com/jayli/jayli.github.com/issues/1