【譯】前端開發者的基本要求
本文轉載於:猿2048網站【譯】前端開發者的基本要求
備註：第一次翻譯技術文章，標題都糾結了好久不知道腫麼翻譯，如發現翻譯不當之處，可點選github連結提交評論，thx～
前幾天我為一個專案寫README文件，我希望其他開發者能夠看到這個專案，並從中學到一些東西。突然我意識到，若放在幾年前，我寫作的過程中隨口提到的Node，npm，Homebrew，git，測試還有產品構建，會把我魂都嚇沒了。
曾經有段時間，一個前端開工程師基本的工作流程是：編輯檔案，本地測試下（盡我們可能做到最好），然後通過FTP上傳到伺服器。我們評價一個前端工程師的水平，是通過他是否能夠相容IE6，或者取得跨瀏覽器的畫素級的一致。很多社群的成員——包括我在內——缺少傳統的程式設計經驗。HTML、CSS和JavaScript——通常指jQuery——是自學的技能。
這些事情在過去的幾年裡發生了變化。可能是因為大家開始認真的看待前端開發者的工作，或者是因為瀏覽器開發商開始臭味相投（趨向一致？原句getting their shit together），又或者是前端開發者自己——同樣，包括我在內——開始看到軟體開發變得完善的曙光。
不管怎麼說，我們看到前端開發的重點，從繁瑣轉向了重視工具化。想要成為一名成功的前端開發者，你需要掌握一套新的基礎技能，而不滿足要求的前端開發者會感覺到落後越來越多，而那些正在分享他們知識的工程師們覺得這些事情是自然而然的。
下面提到的一些內容是我希望人們能夠熟悉的，除此之外還有一些相關的資源，如果你覺得你需要在成長的道路上加速的話。（感謝Paul Irish，Mike Taylor，Angus Croll，以及Vlad Fillppov的貢獻）
JavaScript
這個不用多說，但僅僅知道一個javascript庫再也不夠了。我並不是說你需要知道如何用原生的JavaScript實現一個JavaScript庫的所有特性，但你需要知道，什麼時候的確需要用庫，同時，在不需要用庫的時候，有能力用簡單而古老的JavaScript完成你的工作。
這意味著，你已經讀過《JavaScript語言精粹》—— 希望不止一次。你理解像物件、陣列這樣的資料結構；函式，包括如何、為什麼你需要～call
和apply
他們；掌握原型繼承；掌握javascript的非同步操作。
如果你的原生JS比較弱，這裡有一些資源可以幫到你：
- 《JavaScript程式設計精解》：一本可以帶你迴歸JavaScript基礎的書，挺不錯的（有紙質版的）
- 《測試驅動的JS評價》：一系列失敗測試，它們覆蓋了不同的JavaScript主題；你能夠編寫讓測試通過的程式碼嗎？
- 《我從jQuery原始碼中學到的10點》：Paul Irish給我們帶來的禮物，雖然比較舊，但的確不錯，它讓我們知道從閱讀他人的程式碼中所能學到的東西。
Git（還有一個Github賬戶）
如果你沒訪問過Github，你絕對無法參與到這個資源豐富的開源社群中來，它已經在前端開發技術領域呈現欣欣向榮之勢。克隆一個分支然後跑一下應該成為你的習慣，同時你需要知道在多人協作的專案中如何使用分支。
需要提升你的git
技能？
模組化，依賴管理，產品構建
通過在頁面塞幾個script或style標籤來管理依賴的日子已經一去不復返了。即使你還沒能能夠將RequireJS引入你的工作流程中去，也應該找時間在自己的個人專案，或像Backbone Boilerplate這樣的專案裡試下它，因為它能給我們帶來許多好處。RequireJS能夠讓你開發的JS、CSS檔案保持模組化、粒度足夠細，而在產品上線前可以通過配套的優化工具進行檔案壓縮、合併。
AMD聽起來很嚇人？再也沒有藉口什麼也不幹了。至少，你應該知道存在像UglifyJS、Closure Compiler這樣的工具，它們能夠在你的產品上線前，對你的程式碼進行智慧壓縮和合並。
如果你還在寫原生的CSS —— 也就是說，目前沒有用像Sass或者Stylus這樣的CSS前處理器 —— RereireJS也能夠幫你保持你的CSS檔案模組化。在一個基礎樣式檔案裡使用@import
宣告來載入相關依賴檔案，然後對這個基礎檔案執行ReqireJS Optimizer來構建實際生產環境所要用到的檔案。
瀏覽器內建開發者工具
在過去的幾年裡，基於瀏覽器的開發工具已經大大得到了提升，如果你知道怎麼利用好它們的話，它們能夠大大提高你的開發體驗。（提示：如果你還在使用alert
除錯程式碼的話，你會浪費很多時間）
你或許需要確定一款瀏覽器，你主要使用它的開發者工具 —— 近來我比較傾向於使用Google Chrome開發者工具 —— 但不要立即拋棄其他瀏覽器的開發者工具，因為他們經常會根據開發者的反饋來新增有用的特性。特別值得一提的是，Opera的Dragonfly的某些功能讓它的開發者工具與眾不同，比如（尚在實驗中的）CSS分析器，可使用者自定義的鍵盤快捷鍵，無需USB連線的遠端除錯，以及能夠儲存並使用自定義的調色盤。
命令列
說到命令列，適應它(being comfortable with it)再也不是可選項了——如果你沒有準備好坐到終端視窗前，並親自動手敲命令列的話，你一路上會錯過非常多的東西。我並不是說你必須在終端上完成所有事情——我不會搶走你的git GUI（圖形化使用者操作介面），雖然我的確覺得最終你離開它會更好——但不管做什麼專案，你最好一直開著你的命令列終端。下面幾個命令列任務是你必須不假思索就必須能夠完成的：
-
ssh登入另一臺機器或伺服器
-
scp拷貝檔案到另一臺機器或伺服器
-
ack或者grep找到檔名包含某個字串或符合某種模式的檔案
-
find定位檔名符合某種模式的檔案
-
git至少能夠用它完成如下事情：add，commit，status
和pull -
brew通過Homebrew 來安裝檔案
-
npm 安裝Node包
-
gem安裝Ruby包
如果有些命令你用得比較多，你可以編輯.bashrc
- 或者.profile
- 或者.zshrc
- 或者其他，然後建立alias，這樣你就不用像之前那樣敲很多字元。你也可以新增alias到你的~/.gitconfig
檔案裡。Gianni Chiappetta的dofiles是個不錯的範例。
注意：如果你在Windows上開發，我不知道如何幫助你，除了建議使用Cygwin。在Windows上參與前端開源社群的活動比較麻煩，當然我說的不一定正確。相反的，MacBook Air便宜、強大，而且不可思議地便攜，而且總是會有Ubuntu或者各種*nix。
（web前端學習交流群：328058344 禁止閒聊，非喜勿進！）
前端模板
在不久之前，對於前端的XHR請求，伺服器典型的應答方式是返回一段HTML文字。但在過去的12到18個月間，前端開發社群看到了曙光，要求服務端返回單純的資料。將資料轉成HTML是件麻煩的事情，如果處理得不好的話，可維護性會相當糟糕。這就是前端模版庫誕生的目的：你僅需要維護一套模板，在需要的時候提供資料，就能夠將模板轉換成HTML。在模板庫的選擇上需要幫助？Garann Mean的template chooser能夠給你指明方向。
CSS前處理器
Paul Irish前些天注意到，前端開發者編寫的程式碼，跟最終在生產環境部署的差別開始變得很大。通過CSS前處理器寫出來的程式碼就是很好的例子。仍然有不少人堅持說原生的CSS才是唯一的出路，但它們離我們越來越近(but they are starting to come around)。這些工具提供了一些按理來說CSS屬性早就該有的特性，包括——變數、數學運算、邏輯、混合(mixin)，它們能夠幫你從一堆冗餘的特性字首中解放出來。
測試
編寫模組化、鬆耦合程式碼的樂趣之一就是，你的程式碼變得很容測試。如果你用了Grunt這樣的工具，建立一個包含測試用例的專案再簡單不過了。雖然Grunt集成了QUnit，但是還有許多測框架供你選擇——Jasmine和Mocha是我喜歡的兩個測試框架——框架的選擇取決於你的個人偏好，以及你專案的結構(the mark up of the rest of your stack)。
如果你的程式碼是模組化、鬆耦合的，測試是件有趣的事情。然而，對於那些組織糟糕的程式碼，測試不單困難，有時甚至不可能的。換句話說，強迫自己編寫測試用例——甚至可能在你正式編碼之前——有助於幫你理清你的思路以及你的程式碼組織。後續當你重構你的程式碼的時候，它也能讓你充滿自信。
我錄製的一段很短的視訊，關於如何使用Jasmine測試jQuery
一個jquery-bbq外掛單元測試的例子
流程自動化(rake/make/grunt/其他)
流程自動化的一個例子：通過Grunt建立內建單元測試的專案。前端開發的現狀是，我們有一大堆重複性的工作需要做，但有個朋友曾經告訴我，一個好的開發者是個“懶惰”的開發者：首要的一點是，如果你發現自己做同一件同樣的事件超過三次，那麼是時候將它變成自動化的。
像make這樣的工具已經存在很長一段時間，主要用來幫我們解決上述問題，但也有類似rake、grunt
以及其他類似的工具。如果你想把跟需要跟檔案系統打交道的任務變成自動化，學習一門JavaScript以外的語言非常有幫助，因為當你僅僅想要處理檔案時，Node的非同步特性會讓事情變得更加麻煩。也有許多針對特定任務的自動化工具——部署，構建，程式碼質量保證，還有其他。
程式碼質量
如果你曾經被缺失分號，或多一個逗號這樣的問題困擾過， 你就知道這樣小的程式碼缺陷可以浪費你多少時間。這就是為什麼你正在類似JSHint這樣的工具裡執行你的程式碼，沒錯吧？它不僅可配置，而且有很多方式可以將它整合到你的編輯器或構建流程中去。
好的參考手冊
唉，沒有針對前端開發的手冊，但MDN觸手可及。好的前端開發者會在任何搜尋查詢里加上mdn字首，比如mdn javascript arrays
，避免搜到像w3schools那樣的盈利性組織的內容。
結尾
閱讀上面這些東西沒辦法讓你成為一個專家，哪怕是變得更有經驗些——在某件事情上做得更好的唯一途徑就是做那件事<