少妇的味道4,少妇2做爰HD韩国电影,少妇免费直播,少妇献身HD中字,少妇高潮毛片免费观看A京东热,法国少妇愉情理伦片

從2012年到現(xiàn)在，一篇文章都沒發(fā)過讓我覺得有點(diǎn)羞羞噠。三年是一段很長的時(shí)間，很多東西都發(fā)生了改變。2012年，我鼓勵(lì)同學(xué)們?nèi)W(xué)習(xí)瀏覽器開發(fā)者工具和模塊化；雖然有很多同學(xué)會(huì)覺得CSS預(yù)編譯和客戶端模板引擎并不靠譜，但我仍然想要說一說它們；還有JSHint，雖然有#getoffmylawn（滾出我的地盤）的警告，但依然無法阻止JSHint成為一個(gè)受歡迎的理念（準(zhǔn)確的說，JSLint真的（只是）存在過）。 

已經(jīng)是2015年了，我想寫一篇新的，但是當(dāng)我坐下來開始動(dòng)筆的時(shí)候，想到了兩個(gè)事情。一，這些東西被稱作“必知必會(huì)”可能有人會(huì)覺得不太公平——如果你已經(jīng)覺得2012年的那篇文章如此，那本文也是一樣的了。也許有同學(xué)會(huì)說，我們應(yīng)該把 “足夠應(yīng)付業(yè)務(wù)需求的技能” 作為 “前端必須掌握的知識(shí)”，但考慮到前端行業(yè)里也有各種各樣的工作可供選擇，這么做也只能得到一個(gè)并不適合所有人的 “前端基礎(chǔ)知識(shí)”。對(duì)于我來說，我需要的不是工作，我想要的是被邀請(qǐng)去做一份牛逼的工作。我想要的不只是去干活而已，而是想和一群牛逼的人一起做牛逼的事。我不想僅僅滿足于用已有的知識(shí)來完成現(xiàn)在的工作，而是希望掌握更多的知識(shí)來解決未來將會(huì)面對(duì)的問題。 

第二，我現(xiàn)在已經(jīng)完全把Javascript作為我的核心了：CSS知識(shí)只有在必須關(guān)注性能問題時(shí)才會(huì)用到，其他場景已經(jīng)用的越來越少。我知道有很多牛逼的前端同學(xué)并不是這樣的，但我也意識(shí)到，關(guān)注JS的同學(xué)和關(guān)注CSS的同學(xué)之間的距離也越來越遠(yuǎn)。這可能需要在另起一篇文章來討論，不過我想說的是，這篇文章中不會(huì)有介紹CSS技能標(biāo)準(zhǔn)的內(nèi)容，因?yàn)槲疫€遠(yuǎn)遠(yuǎn)沒有達(dá)到能那么做的水平。 

總之，就算這個(gè)技能列表并不適合你的前端工作，沒關(guān)系，不要有壓力，地球也不會(huì)爆炸。 

JavaScript 

回想2009年，那時(shí)候當(dāng)你知道 HTML5 在2014年才能用的時(shí)候，你是不是覺得這輩子基本上都用不到它了？如果是，那么你需要準(zhǔn)備好接受進(jìn)展緩慢但是已經(jīng)趨于穩(wěn)定的ES6了，它也是下一代的Javascript（現(xiàn)在叫 ES2015 了，嗯，這名字至少表示今年就能用了）。就我而言，ES6，額，ES2015 無疑是我個(gè)人現(xiàn)在最關(guān)注的 Javascript 內(nèi)容。在 ES6 中將會(huì)出現(xiàn)一些比較大的變化：類，真正的私有，經(jīng)過改進(jìn)更易用的函數(shù)和參數(shù)設(shè)定，可導(dǎo)入的模塊，等等等等。那些掌握和理解新的語法的同學(xué)以后將會(huì)在 JS 社區(qū)牛逼閃閃。相關(guān)閱讀： 

Understanding ES6，Nicholas Zakas 正在寫的書。 
BabelJS，一個(gè)可以把你寫的 ES6 的代碼編譯成 ES5 并在現(xiàn)代瀏覽器中運(yùn)行的工具。他們也有一個(gè)不錯(cuò)的介紹 ES6 的文檔。 
ES6 Rocks，里面有大量的文章探索 ES6 的特性，語義和缺陷。 
你也許會(huì)問：那我需要成為一個(gè) ES6 專家么？也許現(xiàn)在不需要，但至少你得和你的同事懂的一樣多吧？或者比他們稍微多一點(diǎn)？當(dāng)然，如果能在你的下一個(gè)新項(xiàng)目中作為一個(gè)娛樂性的技術(shù)嘗試也是不錯(cuò)的，做好準(zhǔn)備肯定沒錯(cuò)的，因?yàn)槲覀冇肋h(yuǎn)不知道下一刻會(huì)發(fā)生什么。 

先不說新的語言特性，使用回調(diào)和 promises 管理異步 Javascript 至少得背的滾瓜爛熟吧。瀏覽器端應(yīng)用加載，以及應(yīng)用間通信策略得形成一套自己的觀點(diǎn)吧。而且你應(yīng)該知道哪種框架最適合你，而不是現(xiàn)在還把時(shí)間花在理解各種框架的實(shí)現(xiàn)原理和該選擇哪種框架上。 
模塊化和構(gòu)建工具 

毫無疑問，模塊化是構(gòu)建 Web 客戶端應(yīng)用的基石。回到2012年，關(guān)于使用哪種模塊化（ADM/CommonJS）方案構(gòu)建瀏覽器端應(yīng)用還存在很多爭論。而最近慢慢火起來的UMD則在保證代碼可復(fù)用的前提下嘗試避免這樣的問題。 其實(shí)也沒什么好爭得，畢竟這倆玩意兒之間也就差幾個(gè)字符吧？ 

我覺得類似這樣的爭論其實(shí)并不都需要有一個(gè)答案，這也是我覺得從2012年到現(xiàn)在我們發(fā)生的最大的轉(zhuǎn)變，當(dāng)然，也許只是我自己這么認(rèn)為。因?yàn)槲矣X得與其說“我再也不用 AMD 了”之類的話，倒不如多去討論 “在開發(fā)和打包過程中使用 CommonJS 和 npm 遇到的各種難題” 來的更有價(jià)值。 

雖然很感激RequireJS曾經(jīng)對(duì)模塊化做出的貢獻(xiàn)，不過現(xiàn)在我開始有點(diǎn)迷戀webpack了。 webpack 的構(gòu)建配置比 RequireJS 更加易于理解，也更具訪問性。通過它的熱插拔特性和內(nèi)置的本地靜態(tài)服務(wù)器可以讓發(fā)布更加便捷。它并不強(qiáng)制要求使用 AMD 或者 CommonJS – 兩個(gè)它都支持。它還實(shí)現(xiàn)了一大堆加載器，用來完成常見的繁瑣工作。Browserify也值得去了解一下，不過我個(gè)人認(rèn)為它比 Webpack 落后很多。一些靠譜的朋友告訴我說systemjs也是這個(gè)領(lǐng)域的競爭者，不過我還沒有用過，而且它的文檔爛的我連看都不想看。不過我覺得它的好基友 jspm (包管理器)比較有趣，jspm 可以讓你從各種包管理服務(wù)器加載你需要的各種組件，(組件必須是符合 ES6, AMD, CommonJS and globals 規(guī)范的)，包括 npm, github 等，但是我對(duì)于這兩個(gè)玩意的合體還是有點(diǎn)不太理解。啊，還有，雖然我說了這么多關(guān)于模塊化之外的內(nèi)容，但我從來沒想過放棄 AMD，我們邊走邊看吧。 

我覺得如果要停止對(duì)模塊化和構(gòu)建工具的爭論，形成統(tǒng)一的模塊化系統(tǒng)，并且在這個(gè)系統(tǒng)里面，任何項(xiàng)目的代碼都可以共享，而且還不需要 UMD 這樣額外的補(bǔ)丁工具，我們還有很長的路要走。理想狀況下，ES6 modules 的到來會(huì)解決這些問題，不過在這一天到來之前，類似 UMD 之類的轉(zhuǎn)換器會(huì)填補(bǔ)這些空缺，不過貌似這樣做我們又把事情變得復(fù)雜了，好像我們也總喜歡把事情弄得復(fù)雜。 

與此同時(shí)，前端開發(fā)人員也需要對(duì)構(gòu)建工具，各種模塊化系統(tǒng)有自己的見解和知識(shí)儲(chǔ)備。不管是好是壞，根據(jù) Javascript 現(xiàn)在的進(jìn)度，你的模塊化策略會(huì)對(duì)你的項(xiàng)目有比較大的影響。 

測(cè)試 

客戶端的代碼測(cè)試變得越來越普遍，最近也誕生了一些新的測(cè)試框架：Karma，Intern。我發(fā)現(xiàn)基于 promise 的 Intern 的異步測(cè)試方法相當(dāng)優(yōu)雅。不過可能是因?yàn)榱?xí)慣，我大多數(shù)情況下還是用 Mocha 寫測(cè)試用例。 

測(cè)試的主要障礙其實(shí)是前端開發(fā)者的代碼編寫方式。我在2012年發(fā)表過一個(gè)關(guān)于《編寫可測(cè)試的Javascript》下載地址的演講，緊接著幾個(gè)月后又發(fā)表了一篇相關(guān)的文章。 

測(cè)試的第二大障礙是工具。Webdriver 是一個(gè)艱難而巨大的工作。目前在各個(gè)瀏覽器端做持續(xù)集成的 UI 自動(dòng)化測(cè)試基本上是不可能的，更不用說移動(dòng)端了。我們?nèi)匀煌Ａ粼诰窒抻谀骋恍〔糠譃g覽器和設(shè)備上做輕量級(jí)的自動(dòng)化功能測(cè)試，盡我們所能去研究怎樣快速，低成本的進(jìn)行這種測(cè)試的階段。 

如果你對(duì)如何改進(jìn)代碼的可測(cè)試性感興趣的話，那么唯一一本最值得看的書是 Working Effectively with Legacy Code （中譯版：《修改代碼的藝術(shù)》。作者M(jìn)ichael Feathers定義了“遺留代碼”的概念：任何未經(jīng)測(cè)試的代碼都是遺留代碼。在測(cè)試領(lǐng)域，最基本的要素就是上面這句話，盡管你可能不這么認(rèn)為。 

流程自動(dòng)化 

你首先會(huì)想到Grunt，這也是理所當(dāng)然的。而 Gulp和Broccoli的自動(dòng)化構(gòu)建方式也別具匠心。我沒用過Broccoli，只玩過Gulp，我也開始意識(shí)到Grunt對(duì)于依賴其他服務(wù)的復(fù)雜任務(wù)的自動(dòng)化工作存在局限性，尤其是當(dāng)這種任務(wù)每天需要運(yùn)行上千次的時(shí)候。 

Yeoman是在我寫完2012年的那篇文章僅僅45天之后發(fā)布的，我承認(rèn)當(dāng)時(shí)我并沒有及時(shí)去嘗試一下。不過最近我開始啟動(dòng)一些新項(xiàng)目，這些新項(xiàng)目有兩個(gè)特點(diǎn) 
a) 這些項(xiàng)目都是從零開始 
b) 嘗試用一些不同的技術(shù)方案，試圖通過這種方式找到 Bazaarvoice（提供第三方點(diǎn)評(píng)服務(wù)）上第三方 JS 應(yīng)用的規(guī)范化的開發(fā)方式。 
Yeoman 在這兩方面做的都很好。一個(gè)簡單的 yo react-webpack 命令就可以為你初始化好你的項(xiàng)目，然后各種你想要的玩具也都應(yīng)有盡有：生成測(cè)試用例，本地靜態(tài)服務(wù)器，hello world 入門程序，等等等等。如果 React 和 webpack 不是你想要的，也許你會(huì)在 Yeoman 的 generators（項(xiàng)目生成器）里面找到一個(gè)你想要的，當(dāng)然，自己自定義一個(gè)這樣的構(gòu)建包也是比較容易的。 

鑒于Yeoman只是一個(gè)在項(xiàng)目開始時(shí)才會(huì)用到的構(gòu)建工具，并且鑒于我們并不是總是做新項(xiàng)目，所以大多情況下了解一下就夠了。除非，你也想去規(guī)范整個(gè)項(xiàng)目開發(fā)過程，那么它可能會(huì)更有價(jià)值一點(diǎn)。 

Broccoli已經(jīng)得到了 ember-cli 的采納，我覺得他們的配對(duì)可能會(huì)有一個(gè)新名字，這樣在未來才比較方便和 Grunt /Yeoman 對(duì)抗。而 Grunt 和 Yeoman 的開發(fā)進(jìn)度也放緩了，所以未來會(huì)發(fā)生什么，我們還是靜觀其變吧。 

代碼質(zhì)量 

如果你像我一樣，一看見違反代碼規(guī)范的代碼時(shí)就開始抓狂，那么 JSCS 和 
ESLint 就是老天賜給你的禮物，而2012壓根就沒這些玩意。他們都提供了自定義代碼規(guī)范的方式，并且可以在代碼提交前對(duì)你的代碼做自動(dòng)化校驗(yàn)。這讓我想起了… 

Git 

從2012年到現(xiàn)在，github 的使用流程并沒有發(fā)生很大的變化，比如在 pull request 頁面連個(gè)分支名都沒有（只是惡搞一下）。 

你應(yīng)該非常清楚和流暢地使用功能分支（feature branches）, 使用 rebase 合并別人的代碼干活，使用交互式 rebase 命令和 squash 合并提交記錄，或者盡可能細(xì)顆粒度的劃分項(xiàng)目內(nèi)容，避免引起代碼沖突。另一個(gè)可用的 Git 工具是鉤子，具體而言，就是你可以在 push 前，commit 前，執(zhí)行你的各種測(cè)試用例，檢查代碼質(zhì)量。你可以自己寫鉤子，也可以使用 ghooks ，由于 ghooks 使鉤子工作變得非常簡單，所以你簡直沒有理由不用它。 

客戶端模板 

這可能是我在2012年的那篇文章中寫的最爛的內(nèi)容了，某種意義上的“爛”。客戶端模板還是很有價(jià)值的，而且它已經(jīng)被內(nèi)置到 ES2015 里面了，這不僅僅只是一件好事而已。這些年也有一些慘重的教訓(xùn)，不少團(tuán)隊(duì)把所有的渲染工作全部丟到瀏覽器端去做，結(jié)果產(chǎn)生了嚴(yán)重的性能問題，所以 “在瀏覽器端渲染生成所有 HTML” 的做法理所當(dāng)然的被摒棄了。 而更為聰明的做法則是，把 HTML 生成放在服務(wù)器端，或者通過預(yù)編譯的方式，先將模板做為靜態(tài)資源儲(chǔ)存起來，在需要時(shí)快速的編譯成 HTML，需要更新時(shí)也可以直接在客戶端更新模板。 

這里會(huì)有一些新的展望，不僅是對(duì)我自己，也是對(duì)所有人，當(dāng)你在考慮性能問題時(shí)，也許沒必要把自己完全限定在瀏覽器范圍內(nèi)。所以，這又讓我想起了…… 

原文鏈接：A Baseline for Front-End ‘JS’ Developers: 2015 

譯文來自：知乎——前端外刊評(píng)論