前端界有哪些越早知道越好的小技巧、小知識？

01-15

這些技巧，可能是可以事半功倍的一個小軟體，可能只是一個網址，也可能是一個工作經驗，一個簡單的工作技巧，一個小小的建議，也可能是 JavaScript 的一個小特性，一個黑魔法，等等，知道後往往會讓人驚嘆，我要是早點知道該多好！！！當然，有些技巧在 IT 界同樣可以共用。
樓主拋磚引玉，說兩點讓樓主覺得要是早點知道有多好的 "技巧"。
首先是給自己取個唯一的 id，設計個唯一的頭像。

其次是使用 markdown，樓主現在都不想編輯以前不是用 markdown 寫的文章了，誰用誰知道。
希望大家可以獻計獻策，人多力量大！
另外針對一些類似 "學習沒有技巧捷徑" 之類的回復，我想有點誤解樓主提問的意思了~

也請大家幫忙邀請一些樂於分享經驗的大大們~ 謝謝

天哪，居然有沒有人說：打！斷！點！

據我觀察，大部分從非 CS 專業出身的前端工程師（甚至是 CS 專業的前端工程師）都不知道如何進行斷點調試。遇到 bug 的時候打滿屏的 `console.log` 半天還 debug 不出來（但在你學會斷點調試的時候，可能瞬間就精確定位 bug 了）。斷點調試這種最最最基本的技能居然在他們看來如此匪夷所思。

@戴嘉華說了一些 Chrome 開發者工具的技巧，其實並沒有涉及到開發者工具最核心的功能之一：斷點調試。斷點可以讓程序運行到某一行的時候，把程序的整個運行狀態進行凍結。你可以清晰地看到到這一行的所有的作用域變數、函數參數、函數調用堆棧。你可以看到數據是怎麼在程序當中流動的，你還可以修改、把玩它們。斷點調試讓你真正了解一個程序的運作流程。

聽聽亞洲舞王，著名 Web 前端工程師尼古拉斯·趙四是怎麼說的：

「斷點調試是檢驗一個前端工程師 debug 能力的唯一標準；是從初級前端工程師成為中高級前端工程師的必經之路；是了解源碼和程序運行狀態的不二法門！」

看看 IBM 高級工程師，著名IT評論家，王博士怎麼說：

「面試一個前端工程師的時候，我一般給他一個bug，然後看他怎麼打斷點的，一個人的能力在調試過程中一覽無遺。」

除了 debug 的時候會用到，斷點調試在你了解一個第三方庫源碼也很有幫助。精通斷點調試的工程師在閱讀源碼的效率上比打 `console.log` 高效不止一個數量級。所以懂得如何斷點調試，你在 debug 能力、從源碼中學習新知識的能力（包括知識的量）會甩其他工程師好幾條街。

接下來是小白教程，大神繞路。

=============================== 分割線 ==============================

下面是日常打斷點直播，跟著我一步步來，看看斷點調試如何可以讓我們了解一個程序的運行狀態、流程。這裡的例子是： 如何通過斷點調試，了解React.js 的 `setState` 方法到底幹了什麼事情。

建立一個 React 組件渲染到頁面上，App.js 如下：

import React, { Component } from "react";


class App extends Component {

  constructor () {

    super()

    this.state = { name: "World"}

  }
  handleClick () {

    this.setState({ name: "World 2" })

  }
  render() {

    return (

      &

        Hello {this.state.name}

      &
    )

  }

}

export default App

程序很簡單：點擊 div，通過 `setState` 讓原來「Hello World」顯示成「Hello World 2」。

Chrome 打開頁面，F12 或者 option + command + j （Mac 下）打開 Chrome 開發者工具。點擊第三個 tab : Sources。

然後 command + o（windows 應該是 control + o），輸入 App.js 查找我們的文件：

很棒，第一個就是。然後回車，就可以看到文件的內容：

很明顯，這就是我們上述的文件 App.js。點擊 div 的時候就調用 handleClick 方法。handleClick 方法內部有一個 setState 的操作，我們在第 10 行的行號上點一下。

然後點擊一下頁面上的 `Hello World`，

現在整個頁面卡住，什麼都操作不了。這是因為我們的 JavaScript 已經完全在第 10 行暫停了，整個應用程序是凍結的狀態。看看代碼右邊區域：

Watch 是幹嗎的？點擊 Watch 旁邊的?，然後輸入 `this.state` 看看：

Watch 可以幫你監控執行當前斷點所在作用域任何表達式的執行結果，輸入 `this.state.name + "ok"` 看看：

下面 Call Stack 表示這個函數的調用堆棧，也就是 setState 是被哪個上層函數調用的，上層函數又是誰調用的...

Scope 是當前斷點的作用域以及所有的閉包作用域以及全局作用域，你可以看到所有作用域的變數。

右邊的功能不多說了。我們看看怎麼繼續打斷點，滑鼠放到代碼里的 `setState` 函數上：

這裡彈出的信息告訴我們，this.setState 是函數是在 `ReactComponent.js` 這個文件中定義的，而且還是個匿名函數，它接受兩個參數，一個是 partialState，一個是 callback。直接點擊 `ReactComponent.js`，就會到 `setState` 函數定義的地方：

我們看到 `setState` 的原型了，可以看到它其實最主要調用 `this.updater.enqueueSetState` 函數。我們在這一行上點打個斷點：

然後點擊瀏覽器上部的藍色箭頭：

這個箭頭指的是繼續執行代碼，代碼繼續執行，在我們新打的斷點的地方又停住了：

我們在旁邊可以看到我們傳進來的參數：

整個程序的變數猶如裸奔，一覽無遺。繼續把滑鼠放到：

跳到 `ReactUpdateQueue.js` 文件：

繼續跳

你可以發現，到這裡你可以了解到：原來 React.js 的組件實例有兩種，一種是公共實例 `publicInstance`，一種是內部實例 `internalIntance`，內部實例存放在 ReactInstanceMap 當中，每次 `setState` 的時候，先取到內部實例。回到 ReactUpdateQueue.js ，我們一怒之下又打了兩個斷點：

執行：

發現 React 把我們的新的 state push 到了一個叫 queue 的數組中。以下省略 N 次斷點，到了：

又省略了 N 次斷點

...

最後你會了解當點擊頁面的時候，React.js 執行了一個叫 `dispatchEvent` 的方法，然後會 `batchedUpdates` 裡面執行 transaction.perform 一個事務；這個事務會執行一個函數，這個函數最終會調用我們的 handleClick 方法使其得以執行；setState 的時候會把新的 state 放到一個更新隊列裡面，並且把 setState 組件放到一個叫 dirtyComponents 的隊列裡面；

transaction.perform 每次會執行以後都會執行 closeAll，所以當上述的操作執行完以後，會把 transaction 每個 wrapper 都 close 掉。有一個 wapper 會調用 `runBatchedUpdates`，它會遍歷 `dirtyComponents` 然後一個個去執行 `updateComponent`，`updateComponent` 會從 state queue 拿出最新的 state 然後合併，最後更新頁面組件。

上面已經省略了很多細節。但是真實調試過程可能只需要 15 分鐘不到，你就可以大致理解到 React.js 到底了發生了什麼事情。

這些事情你是用 console.log 沒法快速了解到，直接看源碼可能也會一頭霧水。但是斷點調試，方便、快捷、簡單。你值得擁有。但實際上，這些事情對於受過較為正統的 CS 專業的培訓的人來說，是習以為常的事情，就像吃飯、呼吸一樣自然。然而最可怕的是：很多前端工程師都不知道。

Chrome 開發者工具非常強大，可以讓我們非常高效地調試優化代碼。要把它的技巧全部寫出來，估計得寫一整本書。後續可以繼續聊聊。

=============================== 分割線 ==============================

UPDATE：想給那些邏輯思維比較差的「大神」提醒一下，請看清楚文章的語境和邏輯再評論。

寫本答案的初衷是因為本人接觸的前端工程師比較多，而其中很多不會如何使用斷點調試，於是猜想這個現象不是個別現象。所以希望寫下這個答案來給前端剛入門的同學一個教程和指引（而本答案的點贊數和評論來看來確實證實了這個事實）。

再給「大神」們整理一下本文的邏輯鏈：因為存在「很多前端工程師對斷點調試不熟悉」現象的存在，所以認真地整理一個教程和引導，希望能幫助這部分工程師。

而就是有人忽略「很多前端工程師對斷點調試不熟悉」這種事實的存在：

很多這種評論我並沒有回應。因為對於根本看不懂本教程初衷和邏輯的人，其實沒法溝通，你高興就好。但是變本加厲加嘴巴不幹凈是不行的：

大家講道理啊！

建議大家不要看。

寫得比較意識流，將就一下。

1. 讓一個塊級元素在某區域內上下左右居中：

& && &

& .container { border: 1px solid #000; width: 300px; height: 300px; position: relative; }


.box {

border: 1px solid #000;

width: 50px;

height: 50px;

/* magic below */ position: absolute; margin: auto; left: 0; right: 0; top: 0; bottom: 0; /* magic end */ } &

根本不用算什麼百分比啊margin什麼的，本寶寶直接一波 0 0 0 0。

（PS：container 寬高甚至可以用百分比，這樣 box 會動態居中）

UPDATE：有些同學說這是常識，我 CSS 學得比較渣，不要欺負我...

UPDATE：原理就是讓 box 自己既要往左也要往右，既要往上也要往下。這時候它就不知所措了，只好待在中間。

2. Chrome 瀏覽器給 console.log 加樣式：

console.log("%c我%c愛%c你", "font-size: 60px;color: red", "font-size: 40px; color: blue", "font-size: 20px; color: green")

3. 在 Chrome 瀏覽器的 Elements 裡面選中某個元素，按 h 可以隱藏該元素。

4. 在 Chrome 的 Sources 裡面的裡面，ctrl + o 可以打開某個 JS 腳本，並且可以直接修改它，修改的內容在不刷新的情況下是生效的。

5. Currying 多多益善：前端使用面向對象式編程還是函數式編程針對什麼問題用什麼方式分別有什麼具體案例？ - 戴嘉華的回答

2016.06.21 評論中的問題已回復在文末，目前多了62個贊，先更新6條。
有疑問歡迎評論留言或討論。

半夜路過隨意答一些，根據贊的數量不定期update，先寫幾條：

1. 定義文件名稱不要使用一些敏感易被廣告過濾軟體過濾的名稱，如果你線上發布是以hash為文件名或者bundle後的安全模塊名稱可忽略。

2. 書寫文件請確保文件編碼一致，即使使用UTF-8，也要注意是否存在BOM頭。

3. 頁面出現腳本錯誤，如果錯誤顯示是網路相關的，那麼在查看網路請求的時候（調試器-&>網路，或者代理軟體看網路請求）需要注意：

1. 檢查地址是否正確
2. 檢查請求參數
3. 看看是否是被瀏覽器插件阻攔（如果有CLIENT_BLOCK等消息，直接忽略前兩個檢查項目）
4. 然後優先檢查本地的hosts文件是否錯誤綁定伺服器名稱
5. 次要檢查全局代理（系統、瀏覽器），是否使用無效代理
6. 再次檢查使用的網路服務的DNS，看看是不是DNS服務出錯
7. 再來檢查你的發布機記錄以及伺服器上的文件改動，找蛛絲馬跡
8. 或者你應該重啟一下瀏覽器，233（優先保留現場，別著急重啟瀏覽器或者系統）

4. 依賴本地儲存的網頁可能存在比較嚴重的安全問題，localStorage/cookies/indexDB中讀取的數據，尤其是腳本是不可靠的，不要重度依賴這個方法，因為誰都可以clear或者替換你的內容。（包括惡意利用者）

5. 跨域頭不要圖一時爽快設置Allow:*，要設置域名白名單，最高效的方案是在NGINX等伺服器上直接做，當然，你考慮代碼可維護性，也可以在語言層做。

6. 不要以為寫完代碼壓縮後上傳就大功告成了，老版本的壓縮工具多數有BUG，以及不要隨意變換壓縮工具，壓縮後的代碼請再次進行測試。

7. 線上調試並非不可取，如果公司有相對友好的預發測試環境，或者線上調試載入機制（諸如淘寶），那麼DEBUG會簡單的多，如果沒有，那麼可以使用charles之類的代理軟體來輔助你在上線前使用你的新腳本來進行簡單的測試。

8. 代碼LINT很有必要，在根據不同的項目類型（包括項目生命周期）確定不同的LINT配置後，在你push或者release前調用LINT工具檢查一發吧（其實每次調試前都順手LINT下，會避免很多問題）

9. 帶有本地操作記錄的編輯器或許更適合頻繁調試查看的前端開發者，諸如intellj idea 有本地操作記錄，即使你的代碼沒有被倉庫記錄，誤刪除掉了，也可以恢復回來。（創建同路徑路同名文件，即可）

10. 多和你的同事討論，不要閉門造車，傾聽很重要，有效溝通更重要。

11. 接上一條簡單說一下，你周圍一定會有『看起來』哪哪都不行，或者混跡於公司的老同事（阿里慣稱老白兔），然而建議你懷著尊敬謙卑的心態去接觸（不是一股腦的模仿學習），你會發現牛逼的地方是真牛逼，以及在關鍵時刻他的一兩下點撥，可以少走太多彎路。

12. 技術選型可以low，但是要能夠覆蓋未來一段時間的需求變化，避免從底層重構，或者大的架構調整，優先考慮團隊里大家都能上手的，這樣對於項目質量的保障會高，你調休的時候，找人接手也方便，何樂而不為。

13. 閉源有閉源的問題，開源有開源的問題，不要做輪子黨，啥啥都傻乎乎的自己寫，也不要做伸手黨，啥啥都copy或者git clone，提前考慮好內部依賴和外部依賴的各種模塊的管理問題，是否有持續性，安全風險等，這個組件/模塊生命力如何，當外部依賴不能需求滿足的時候，是隨著人家的版本做patch解決呢，還是要做同類型組件替換呢，還是只是多寫幾行業務邏輯就可以了。

14. 一般來說聯調和相對複雜的界面行為測試（尤其是沒有完備的測試條件）相比較開發會花費大量時間。聯調時，先確認誰來帶節奏推進度（和崗位無關，和性格有關），然後儘可能把介面REST化，如果不可避免的不能REST，前端優先在本地使用代理工具進行mock模擬，把流程跑通（相比較後端，前端調試成本真的更低），然後再進行對接，調試出現問題，基本一次性就能鎖定問題到請求參數、請求地址、網路的問題，避免前端代碼出錯造成時間浪費。

15. 接上條繼續說，簡單的界面測試點點點效率最高（能幾步點完，不需要輸入數據的，不要亂折騰，需要輸入數據的，可以寫死一段函數，自動模擬操作和輸入），複雜的抖個包袱，以後說。

16.繼續接上條說非界面測試，諸如介面，或者邏輯測試，可以使用mock工具/proxy工具/test工具進行測試，比較有代表性的舉幾個例子（該付廣告費的，請加微信，手動微笑）：mockjs / fiddler、charles、chrome fiddler / mocha ...

接下來回複評論中的疑問：

@loveky 同學的疑惑，為什麼localStorage這種本地儲存都是受限於同源策略....

先聊聊這個特性，ls/ss提供了本地持久化和臨時持久化的儲存介面，但是它沒有類似Cookie一樣做各種限制，諸如HTTP Only，Path限定，時間檢查等；

再說說一般什麼時候會使用：業務線想提高頁面性能，會把網頁HTML片段，或者JS模板，甚至JS模塊，CSS樣式一併存進去，減少請求介面或者文件的次數；或者是業務線想做當前頁面的狀態標記，把一直環境變數儲存下來。

那麼隱患在哪裡呢，主要在於兩點：

其一，數據有效性難以保證，因為沒有限定Path，不同頁面的腳本都可以存儲同樣的KEY，數據存在被污染的問題，需要使用約定的方式規避儲存欄位的使用（同Cookie），且需要對業務代碼進行掃描，不允許全局組件以外的工具進行錯誤的clear/set操作，以免發生一些小杯具。
同時，不同瀏覽器client 對於本地記錄的數據條數和容量有限制，且不同樣本之間存在差異（有20M寫滿的，有幾個G還能寫的），盲目儲存不可取。

其二，當前域名下，只要存在XSS攻擊，濫用LS的腳本就會是用戶的豬隊友，比如現在某些電商和門戶，把VM甚至腳本直接存到本地，讀取執行的時候也沒有添加有效的Calc Hash機制，導致一旦存在XSS，本地存的腳本、樣式、模板不但可以被利用，還能讀取轉發用戶之前的隱私或者敏感信息。
額外的事情，在第一點中，如果你進行了本地儲存按需分配，某業務線或者項目有固定的LS儲存欄位，當用戶打開兩個Tab的時，會不會出現新舊數據來回覆蓋的事情呢？

以上，在淘寶做全局組件/在美團做單頁支付/WEB統計SDK的時候都有做一些規避。

@andy andy 缺乏溝通，有社交恐懼怎麼辦？

主動的方案，去英語角之類的鍛煉自己和陌生人交流/被動方案，找個開放活潑的團隊。

@楊四覺得前端工作很瑣碎並且白天極易被打斷效率低怎麼辦

瑣碎的東西可以被整理歸納，然後就可以系統而不瑣碎。

和打斷你的人說你是法系職業，吟唱的時候不希望被打斷（誤）

和打斷你的人去溝通，只在固定時間進行溝通，或者把她/他/它要表達的事情列一個清單，一次性給你，當然，如果你們有事務跟蹤(trac/task)系統，就更好了。

1. 從第一天工作開始就要給自己的職業定個未來目標：

是想當個切圖頁面仔還是想做前端結構師、前端技術專家或者是往交互上轉

不要以為這些問題離自己很久遠，當你走一步算一步，等過了幾年回頭看的時候發現自己每天只是在做重複工作,沒太大長進

2. sublime的插件多去裝幾個，代碼能有提示補全的就別自己敲了，一年不知能省多少時間呢

3. 當你發現同樣的代碼寫了快三遍以上的時候，就要開始考慮是不是可以通過寫腳本的方式加快你的節奏了。千萬別懶得寫腳本，因為你會因為一次又一次重複的事花費大量時間

4. 使用一些chrome的liveload插件或者grunt、glup這些構建工具的liveload插件，這樣可以邊寫代碼變自動刷新頁面，實時看效果

-----------------------------------2016-07-14 更------------------------------------------------

5. 養成寫注釋的習慣，不然過兩天連你自己都看不懂

6. 正則表達式估計會經常寫，好好學學，同時靈活使用 oschina上的在線正則測試工具，很方便. 地址在線正則表達式測試

7. 當想實現某種頁面效果，不過是樣式或者是動畫效果，第一反應不要自己動手寫，99%的情況下有人寫好了，並且代碼會很不錯，去參考別人的，不要重複造輪子。去哪找？google或者github

暫時先醬了

奇技淫巧能解決的是眼前的事情。要想有質變，需要長期堅持和積澱。

- 提高英文水平（聽說讀寫）；

- 脫離你的滑鼠（包括 windows 系統上）；

- 學習使用 Vim（以後 ssh 必不可少）；

- 學會 shell/bash（馳騁在 Unix/Linux 系統中）；

- 早早適應 Mac 系統（Mac 是前端的標配）；

- 找一個可多端同步的平台聚集自己的收藏，建立知識索引庫（建議別用 Evernote）；

- 找一個穩定的平台（github 吧），堅持寫博客，時間久了，你會感覺自己在改變。

再偷偷告訴你一個「小技巧」：把犀牛書和基礎演算法輸入到腦子裡，紮實的基礎很重要；）

不會寫css的人寫出來的css會起反作用，還不如讓他/她先不寫任何css（最多正確使用bootstrap），你以後再單獨往上加。

某日，某大公司要做一個網站，一群專家、老鳥、菜鳥、前端、後台、全棧們彙集一堂討論技術框架。

後台框架的選型討論略顯沉悶，「SpringMVC + MyBatis + Redis」，幾個後台老鳥互相給了個眼色，白紙黑字寫了下來。本想有所作為的全棧們似乎想要說些什麼，奈何自己勢單力薄，欲言又止。

前端框架的選型開始了。幾個全棧前端擼了擼袖子，意欲大幹一場。

「用ng吧，google的產品，質量有保證！」老A拋出了一個燙手的山芋。

「ng是什麼？」前端菜鳥小B小聲問旁邊的師父C。

「就是Angular.js，老A就不會說人話。」老C跟小B說。

「笑話！ng用哪個版本？1版問題太多快要被拋棄，2版剛從娘胎里出生走路都還不會呢，誰敢用？」作為全棧代表的老D毫不留情地回擊老A。

「還是backbone好，結合marionette，代碼寫起來還是很爽的！」用慣了backbone的菜鳥小E勇敢地提出了自己的想法。

「backbone框架也太簡單點了吧？要寫好多代碼，做好多重複性工作。」剛被澆了一盆冷水的老A重新挺直了腰板發表意見。

「支持國產，用一下vue.js？」

幾個老鳥紛紛搖頭，「沒怎麼用過不太熟悉啊！」

「react？」

「貌似學習曲線有點高啊！」

「Extjs吧，我用著還是蠻好用的。」眾人紛紛投之以鄙夷的眼神。

「GWT呢？」眾人哄堂大笑

「我建議這個框架選型問題我們先放一邊，我們先來選擇一下用什麼來寫？js？coffeeScript？es6？」一個後台老鳥看不下去了。

「當然是js啊！」

「別老土了，看過2016年的前端流行趨勢沒？以後是es6的天下，我們要有點遠見不是？」

「coffeeScript我覺得也挺好啊，有點小清新的感覺~」

「要不我們試試TypeScript？」

「TypeScript的模塊載入機制很怪啊。」

「用ES6 webpack就可以。」

「不習慣，前端還是用requirejs的好！」

「seajs多簡潔啊，阿里出品，玉伯發起的，我還是他的粉絲呢~」

眼見還是爭執不下，PM過來維護了一下秩序：「這樣討論下去也不是個事兒，我提議這樣，讓這次承擔開發任務的X組組長會議之後做一次技術方案出來，然後大家有針對性的討論。正好現在也到飯點了，大家要不先去吃飯去吧？」

眾人作罷。

「backbone + jQuery2.1 + requirejs + grunt + mocha」 X組組長提出了這一整套技術方案。

「為什麼用jQuery2，不考慮兼容性嗎？」

「jQuery太大了，用zepto代替吧」

「這個網站不是主要在移動端展示嘛，cash體積最小，很合適的！」

「grunt太笨重，gulp多簡潔」

「jasmine測試也不錯」

……

最後，由於項目經理對開發周期的要求，前端選型不得不告一段落，最終的網站只用到了jQuery等幾個簡單的js庫。由於大家對jQuery都很熟悉，所以開發效率很高，再加上幾個前端老鳥的性能調優，整個網站呈現效果頗讓人滿意。

本故事純屬事實，如有雷同，賞個讚唄！

前端的開源和共享的本質造就了前端資源的空前繁榮，同樣也會逼死選擇困難症患者。同時，前端發展這麼快，新框架後浪推前浪，想要對每個框架都了如指掌是很困難的。所謂前端熟手大多數情況下只能對自己熟悉的幾個框架做出合理的評價。然而只是作為框架使用者是很難達到頂尖前端的程度。

如果一定要說一個越早知道越好的小知識：

在你確定需要框架之前，不要迷戀框架，不要過度設計。簡單的往往是最好的。有了紮實的基礎做根蒂，框架不過是浮華雲煙。

前端項目遇到問題時，最有效的解決方式是：rm -rf node_modules npm install

而當後端項目遇到問題時，最有效的辦法就是：新建一個空項目，原封不動複製代碼過去。

工具篇

代碼編輯器：推薦sublime（支持各種插件、主題、設置，使用方便）

1.安裝sublime插件

瀏覽器：推薦Google Chrome，更新快，對前端各種標準提供了非常好的支持

調試工具：推薦Chrome自帶的Chrome develop tools，可以輕鬆查看DOM結構、樣式，通過控制台輸出調試信息，調試javascript，查看網路等

Chrome插件：

liveload: 修改頁面後自動刷新，不用按F5

dimensions：直接在頁面上測量的利器

livestyle：css樣式修改後自動起效果，不需要刷新，elements修改後也能同步到代碼中

image tool：測量，取色

翻牆工具：lantern, 壁虎漫步

電腦：蘋果mac （早早適應 Mac 系統（Mac 是前端的標配））

找一個可多端同步的平台聚集自己的收藏，建立知識索引庫（建議別用 Evernote）

找一個穩定的平台（github 吧），堅持寫博客，時間久了，你會感覺自己在改變

webstorm，神器！幾乎集成了前端都有的環境，更新速度也快。

最重要的是：它可以提醒你的一些疏忽或者很低級的錯誤！而不用自己瞎找半天

理論篇

提高英文水平（聽說讀寫）

脫離你的滑鼠（包括 windows 系統上）

前端自動化，顧名思義減少前端工程師平時處理的繁瑣。比如項目文件的複製切圖的合併 css預處理器的編譯等

一個好的前端工程師，必須也是一個好的後端工程師

養成閱讀英文文檔和英文技術博客的習慣，時間一長你會發現思考問題和解決問題的路徑比之前更為精準有效且持續。

時刻保持對自我前端知識體系建立的警惕和思考，不要因為時髦而衝動，根據自己的階段慎重的判斷知識的優先順序

閱讀前端牛人的博客、文章提升對知識的理解

善用搜索引擎

原生javascript是需要重點掌握的技能，在掌握原生javascript的基礎上推薦熟練掌握jQuery，在實際工作中用處很大

搭建一個屬於自己的博客

交流和溝通能力：這個非常重要，前端同時需要與項目經理、產品、交互、後台打交道，溝通不善會導致很多無用功，延緩項目

知識管理、時間管理：input和output的平衡，output是最好的input。如何做好分享，參與社區，做好交流，作好記錄

對新技術的渴望，以及敢於嘗試

前端的定位關乎到你需要吸收什麼樣的知識和技能，決定在技術世界裡你對什麼需要格外敏感。如果你認為前端僅僅停留在切頁面，實現交互和視覺的要求，那你對前端的認識還停留在初級階段

不用GIT或者SVN就是在自尋死路！

不見設計師設計稿千萬別開工寫界面！否則：「哎呀~你改一下吧」×100次

不見後端的介面文檔千萬別開工寫邏輯！否則：「哎呀~你就調整一下吧」×100次

另外，在html css js代碼中一定要寫好分區注釋，否則當上面的情況出現的時候，呵呵~

二分注釋法找bug~

僅此獻給學習前端一年的自己，同給出自己一年以來的前端體會，望各位在入前端的時候好生考慮，而不是匆匆而入，匆匆而去。

目前前端已經發展到了一年一個框架，一年一個技術棧。一年前我還在學jquery，半年前我在學angular 今年我在學vue。學了這麼多我深深懷疑自己。以後的工作真的用的到這些框架？一個不到兩個頁面的專題頁要用angularjs這種重型高入侵的框架？所以第一點要說的就是脫離了實際項目去學框架=無用功白白浪費了你的學習時間。為什麼這麼說？框架的發明是為了提高開發效率。既然是為了提高開發效率自然相對學習難度也不會太大。框架都是基於js開發那麼如果你js功力深厚然後去學習一門新的框架使用豈不是手到擒來？

我認為前端工程師入門不應該去學各種框架的使用，而是去研究js深層次使用比如《你不知道的JavaScript》這本書比較薄其中說了一大堆js深層次的內容相信看過後絕對會恍然大悟原來你是這樣的JavaScript。

第二點前端工程師不應該也不能僅僅滿足前端知識的學習。前端工程師脫離了後端很難在個人市場上生存下來。幸好nodejs的出生能讓我們這些前端工程師接觸到後端層面。但nodejs目前階段更多的是作為tools/view上。實際的項目開發中很少公司會用nodejs作為後端層處理業務邏輯資料庫操作等。但是nodejs有助於提升前端工程師的個人知識層面比如get與post請求 restful api 後端是如何渲染生成一個頁面的？頁面中的數據是如何從資料庫查找並獲取出來的？這些與前端都是截然不同的知識體系。山重水複疑無路柳暗花明又一村。

第三點前端自動化。

前端需要處理的項目文件比較多而js這門語言在es5階段沒有提供import 文件導入功能。導致各種模塊載入庫的出現比如 require.js 幸好es6在語法層面就提供了import 那麼在目前es5的瀏覽器上要想支持es6可以通過babel來轉換。要用babel那麼不能不提到前端自動化。

前端自動化，顧名思義減少前端工程師平時處理的繁瑣。比如項目文件的複製切圖的合併 css預處理器的編譯等。

所以前端自動化有必要去學習一下學完後用起來特別爽真的不騙你。

第四點移動設備的適配

這是一個大話題，隨著移動設備的發展，pc頁面不得不做響應式設計通常我們會用media查詢來完成，但隨著項目的複雜度要寫大量的媒體查詢這個時候可以用bootstarp框架來幫助我們減少工作量。當然除此之外還有各種解決辦法。

寫到現在我的思路已經不太清楚了。因為前端涉及的範圍太廣了桌面應用，html5遊戲開發，canvas繪圖，等等前端工程師畢竟也是有工程師頭銜的職位了。希望不僅僅是把他當做完成簡單頁面特效的一項工作，前端還有更多的要去研究。

寫到最後我希望前端工程師不僅僅只做一名前端工程師。 fullstack才是前端工程師的真正目標。

天行健，君子以自強不息。

====

2016-7-8 19:01:38更新

移動端頁面與APP開發

我相信未來的潮流,或者說現在就已經是移動端頁面的天下了.這也是為什麼手游之所以那麼多. 我們耗費在手機上的時間已經大於在PC上的時間了. 以及react native 阿里的weex. 這促使我們前端工程師不得不掌握更多的技能(已經學不過來了(′д｀ )…彡…彡) 目前的前端工程師都由後端/設計/.. 轉過來的..看起來很簡單的東西實際上坑還是挺多.包括我們前端工程師如果不了解某些APP開發流程都不好意思寫頁面了..(@1x @2x @3x的圖片,基準解析度.rem布局.設計稿的三種不同形式).

多方面發展

離開了前端..後端仍然能夠寫前端..離開了後端..前端依然還是前端.. nodejs是一門很好讓我們了解後端的開發流程..強烈推薦去學習一下. 如果你遇到了各種非同步流程式控制制那麼就去學es6吧.

es6也是一種趨勢.尤其是新增了箭頭函數讓this不再難以理解有木有~

====

2016-9-30 16:03:28更新

GitHub,GitHub,GitHub.

歡迎大家加入全球最大的同xing交友網站.

為什麼會推薦GitHub呢? 前端開發的時候,當你在百度搜索到一個開發庫的時候.發現更新日期是幾年前了,而且又沒人維護. 那麼這個時候你就可以利用GitHub去搜索相關的庫.

比如你要搜索一個parseUrl的庫. 發現在百度/谷歌一番搜索後無果. 那麼你可以利用github去搜索

首先輸入關鍵詞,推薦分開搜索.

其次選擇JavaScript

然後再右側選擇 most stars

接著你就挑前一頁最新的庫進去看看能否符合你的要求.

為什麼會推薦GitHub呢？

從程序的健壯性和維護性來說,有維護,測試的庫比沒有的庫要好的很多. 至少出bug了還能去提個issues

如果遇到英文不懂.請先百度相關庫看看能否找到中文文檔或者資料.

然後再回頭看範例.

接著就使用吧.

坑這東西.不踩過怎麼知道是坑？

====

越深入前端，越想當初咋不搞後端呢

有兩個很小的技巧：

塊級元素居中

除了使用 margin 負數和 @戴嘉華提到的 magic 方法，還有下面的方法，個人覺得更 make sence 一些，不過需要支持 CSS3。

& &In the center& &

.container { position: relative; }

.center { position: absolute; right: 50%; bottom: 50%; transform: translate(-50%, -50%); }

上面 transform: translate(-50%, -50%) 這條實際上就是以前的 margin 負數的簡化不需要計算元素高度、寬度版。

pointer-events

設置 pointer-events: none 之後，可以讓改元素不響應滑鼠的任何事件，但不影響其他元素響應滑鼠事件，包括被該元素擋住的。如果頁面有一個蒙層，但是又希望用戶可以操作（點擊、選中等）蒙層下的元素，這個時間設置這個屬性就非常有用。

不要亂用炫酷的插件，不能輕信自我吹噓

1.小技巧

[] == ![]

!!等效於 Boolean()

不使用第三個數交換兩個數的數值，效率真的很高喲：

a = a ^ b;

b = a ^ b;

a = a ^ b;

善用%c、
、color，控制台也可以很好玩：

console是個神奇的對象，它不止只有console.log()這一個：

console.error() 輸出錯誤。

console.time()和console.timeEnd()同時使用，命名一致，將執行代碼包含到中間可以監控代碼運行時間：

等等等等，console有一堆好玩的東西。

在Chrome下，如果當前頁面沒有引用jQuery，那麼$也存在，但是它的使用方法跟jQuery的$有些不一樣：

引入了jQuery的頁面：

沒有引入jQuery的頁面：

jQuery返回了內部new的一個jQuery對象，為了實現外部無new操作查詢Dom，

而Chrome內置的$則提示說它叫做Common Line API。

即為：

$0~$4則代表了最近5個你選擇過的DOM節點。

$()等效於document.querySelector，查找匹配到的第一個Dom節點：

而在jQuery下它返回的是一個匹配到所有節點的數組，這經常會讓一些人感到疑惑：

如果你想做到查詢所有匹配節點的目的，那麼不妨試試Chrome內置的$$()查詢器吧：

在沒有引入jQuery的環境下，$$()等效於document.querySelectorAll，即為：

2.書籍推薦

《javascript高級程序設計》這本書入門真的非常非常的不錯，還有很多小技巧哦。

相較於它，犀牛書就顯得有點太厚重了，而且內容比較亂，作為工具書還是可以的。

3.常用站點推薦

-1.Mozilla 開發者網路

很全面的API文檔，火狐開發者網站。

-2.World Wide Web Consortium (W3C)

w3c，同為提供很全面的API文檔，需要一些英語基礎。

-3.Can I use... Support tables for HTML5, CSS3, etc

caniuse，一個兼容性檢測網站，提供幾乎現在所有瀏覽器及不同版本的兼容性情況，並針對各種情況有一一不同的解決方案提供。

4.個人博客：

Scott"s Blog

作為一個小白，想結識各路大神，希望大家不吝賜教。

最近看到這兩篇文章

JavaScript 裝逼指南
JavaScript裝逼指南

想起來一個老梗，看看這三行代碼讓你多了解多少javascript的小技巧，複製到控制台看效果

[].forEach.call($$("*"),function(a){ a.style.outline="1px solid #"+(~~(Math.random()*(1&<&<24))).toString(16) })

不太明白的可以看這裡 (從一行代碼裡面學點javascript)

1. 了解http協議以及常用屬性的含義和作用。

原因：開發過程中的效率損耗在溝通過程最為嚴重。比如csrf驗證在請求頭加token參數，ajax提交表單、json、文件時的請求頭和報文的格式。

2. 深刻記憶網頁各部分元素常用命名

相信我，這會讓完美主義者的小夥伴開發的時候少去了很多糾結和重構。

頭：header

內容：content/container

尾：footer

導航：nav

側欄：sidebar

欄目：column

頁面外圍控制整體布局寬度：wrapper

左右中：left

right center

登錄條：loginbar

標誌：logo

廣告：banner

頁面主體：main

熱點：hot

新聞：news

下載：download

子導航：subnav

菜單：menu

子菜單：submenu

搜索：search

友情鏈接：friendlink

頁腳：footer

版權：copyright

滾動：scroll

內容：content

標籤頁：tab

文章列表：list

提示信息：msg

小技巧：tips

欄目標題：title

加入：joinus

指南：guide

服務：service

註冊：register

狀態：status

投票：vote

合作夥伴：partner

3. 我反對不要用或少用jQuery的答案！

而是入門階段最好熟練使用jQuery，這可以讓一個新手較快的體驗到前端開發的樂趣以及深入學習下去的理由（大家都在鄙視jQuery，那我要學學更牛逼的東西）。

理由；新手入門的門檻在於對概念的理解，剛入門前端的同學不可能做到對一個web應用開發所包括的部分、流程以及涉及到的相關概念理解到位，尤其現在處於前端家爭鳴的時代，各類框架和工具所代表的開發思想有很多來源於桌面端端和後台，這些概念對前端同學（非計算機專業）來說很陌生，MVC、MTV、MVVM、面向對象等。如果是切圖入門的前端對內存、數據結構、緩存等概念了解程度並不高。

這時候上手遠遠比深入學習原理更加能鼓舞人在這條路上走下去。

畢竟大家眼中覺得再簡單不過的jQuery減少了巨大的dom操作的開發工作量。還有，既然大家都覺得簡單的不屑一顧的東西，是不是就意味著入門門檻很低呢？嘻嘻～

1. Google

2. Google

3. Google

能解決你碰到 80% 的問題。

最後介紹一種很有用但又很少被提及的前端技能：Bookmarklet

Bookmarklet編寫指南

不要學習演算法數據結構，不要關心自動測試，要多切頁面，多背API

- 某當老師