 |
VOOZH | about |
|
VOOZH | about |
我前幾天為一個我所希望其他開發者能看到並且從中學習的計劃寫了一份說明文件，當我在寫的過程中，我意識到裡面有些東西在幾年前可能會嚇到我，就像隨便提到的Node,npm,自製程序,git,測試和開發以及產品設立。
以前，編輯一個文件，本地測試（總之，盡我們所能夠做到的），然後把他們傳輸到伺服器上，這是前端開發者的基本工作流程。根據我們對IE6的服從或者達到跨瀏覽器完美像素爭論，我們衡量到我們的奮鬥精神。許多社區的成員--包括我自己--缺乏傳統編程經驗的。HTML,CSS和腳本語言，經常出現在JQuery的格式里--都是自學而來的。
有些事情在過去的幾年裡已經發生了改變。可能是人們開始嚴格要求前端開發者所導致的結果，也可能是大部分瀏覽器的供應商該死，還可能他也是前端開發者--包括我自己，前來看一下已經被大家所接受的軟體開發過程。
無論是什麼，我認為我們現在只是強調從重視細節轉換成重視工具。為了順利成為一名前端開發者，這裡有一系列新的基線技能要求，而開發者不會滿足那些即將開始又越來越落後的基線作為他們分享他們那些開始假設卻又不必說的知識。
這裡有一些事情我最初是想期待人們能夠熟悉的，如果你覺得自己需要趕上進度，那麼就用你所能夠用到的資源。（感謝 Paul Irish, Mike Taylor, Angus Croll和Vlad Filippov他們的貢獻。）
腳本語言
這裡可能就不用說了，可是簡單知道一個腳本語言的庫不再是足夠的。我不是說你需要知道如何在普通的腳本語言裡面實施一個庫裡面的所有特點，可是你應該知道當一個庫文件確實需要並有效工作在普通舊版腳本語言後，這是不可行的，和管理所有的差異性。
這就意味著你已經讀過了[JavaScript: The Good Parts]--希望不止一次。你懂得數據結構就像對象和數組；方法，包括如何調用和為什麼應用他們，使用原型繼承；管理所有的異步性。
如果你抱怨JS庫是薄弱的，那麼這裡有一些資源能夠幫助你：
如果你不知啊Github上，那麼你基本上就不能參加到這個在前端開發技術興起的豐富開源社區。克隆一個副本並嘗試它應該是其次--你的習慣，而你也應該知道在合作項目中如何去使用分支。
需要加快你的git能力麼？
模塊化，依賴性管理和產品生產通過在頁面上拋出更多的腳本或者樣式標籤的管理依賴性日子已經一去不復返了。即使在工作時你還不能在工作流程上融入像RequireJS這樣的好工具，你也應該在個人計劃中找時間去調查他們或者在一個像Backbone Boilerplate這樣的計劃，因為他們傳達的好處是非常巨大的。RequireJS尤其讓你開發小型的，模塊化的腳本和CSS文件，然後根據產品用法連結並縮小到到它最優化的工具上。
超微半導體表示懷疑？這不是什麼都不做的藉口。至少，你應該意識到就像UglifyJS或者Closure Compiler這樣可以智能化縮小你代碼的工具，也會把那些先前那些削減的文件連結到你的產品當中。
如果你在寫普通的CSS文件，如果你不是使用一個像Sass或者Stylus這樣的預處理器--RequireJS也可以幫你保留CSS的模塊化文件。在基礎文件中採用@import 語句來加載開發依賴，然後在基礎文件為產品創造一個生成文件時，運行RequireJS優化器。
瀏覽器開發工具
經過最近的這幾年，基於瀏覽器的開發工具已經發生了極大的改進了，如果你知道如何去使用它們，他們會顯著地提升你的開發經驗。（提示：如果你依然適用alert去調試你的代碼，那麼，你會耗費許多時間。）
你或許應該找一個主要使用開發者工具的瀏覽器--我偏袒谷歌Chrome的開發者工具一點--可是這不代表忽視了其他瀏覽器的開發工具。因為他們根據開發者的反饋不斷添加有用的新功能。特別是歐鵬瀏覽器的Dragonfly擁有一些可以讓開發工具變得超群的特點，比如一個（實驗性的）CSS分析器，定製鍵盤快捷鍵，無需USB連結的遠程調試和可保存可使用自定義顏色的調色板。
如果你知道瀏覽器開發工具的功能是有限的，那麼（修理這些JQuery）Fixing these jQuery是很很好的調試複習（但不是JQuery的核心），包括怎樣去[步進調試]-一這是改變生活的東西如果你學習使用它的話。
命令行
說到命令行的話，舒服地使用它不再是隨意的--如果你沒有預先親自動手結束一個終端窗口，那麼你會在途中遺漏很多東西。在這裡我不是說你必須在終端里把所有事情都做了--儘管我認為你最終還是離開它比較好，但我不會讓你遠離Git的圖形用戶界面。可是你顯然應該有一個打開終端窗口，無論你的項目在哪裡運行。這裡有一些命令行讓你可以不假思索地使用：
如果這裡的命令你都使用得十分頻繁，那麼你最好修改你的.brashrc或者.profile或者.zshrc或者其他文件，並且創造一個別名可以讓你不必列印那麼多次。你也可以添加一個別名到你的~/.gitconfig文件當中。Gianni Chiappetta的dotfiles 是一個非常優秀的想法。
筆記：如果你是在windows上使用，那麼我不知道從哪一步開始幫助你，除非使用Cygwin，是對也是錯，使用Windows機器並且加入到開源的前端開發者社區實際上是要面對更多困難。好的一方面是,MacBook Airs已經十分便宜和強大，而且還十分便攜，同時還擁有Ubuntu或者其他類*nix系統。
用戶端模板
這不會給伺服器花費太長時間去從HTML片段傳送到XHRs中去，可是有時會持續12-28個月，前端開發論壇知道這一點並且會開始從伺服器開始提前取出所需要的純數據。如果完成後會帶入一些不協調的東西到你的代碼中去的話，這將會是一個繁雜和不可維護的工作，當那些數據轉換HTML格式，同時插入到DOM中，這裡就是[客戶端模板庫]入口：(http://www.slideshare.net/garann/using-templates-to-achieve- awesomer-architecture) 。當一些數據混亂了，比如變成HTML的字符串形式，那麼他們就會讓你去維護這些模板了。如果你需要工具來幫助你獲取某個模板，Garann Means』 的[模板選擇器](http://garann.github.com /template-chooser/) 可以指引你到一個正確的方向。
CSS預處理程序
Paul Irish鑑於當前我們開始發現前端開發者在編寫代碼時會發現產品在結束時不同於的原定方向，而通過CSS預處理器所編寫的程序則在這裡變成一個閃光點。雖然還有一些人覺得純CSS編寫是唯一的路徑，但是他們也開始嘗試這樣做了。這些工具即便讓你舉得有所爭論，不過也應該從現在起在詞彙，數學，邏輯，和其他地方適當使用CSS----他們也可以順暢地使用混亂的CSS前綴屬性。
測試
編寫模塊的其中一個樂事是隨意連結的代碼在你手上會變得極其容易地測試，使用Grunt這樣的工具，設置一個project包含測試已經是在容易不過了，Grunt源於QUnit的集合，根據你的喜好或者有所需要修改的，這裡有一些測試框架可供你去選擇--Jasmine 和 Mocha是我現在最喜歡的組合。
當你的代碼是模塊化和隨意連結的時候，測試會變得很有樂趣。比如測試代碼可能會在難點和不可能的地方顯得條理性不強，另一方面，或者在你寫代碼之前強迫自己進行測試，將會幫助你思考代碼的合理性，這也會讓你在重構你的代碼時變得十分有信心。
Grunt是有能力建立一個帶有內置支持的工程文件，而單元測試就是一個很好的進程自動化例子，現實中前端開發其實是有許多重複性的工作需要我們來做，但之前有個朋友告訴我，一個好的開發者是一個懶惰的開發者：作為一條經驗法則，如果你發現自己重複做同一件事情三次，這就應該自動化進行他了。
工具就像make已經幫助了我們很長時間，其他還有rake,grunt等諸如此類的也一樣。如果你想去進行自動化任務去處理文件系統，那麼學習一門語言就不像JavaScript這樣有用，這裡也有許多特殊任務自動化工具--比如開發工具，代建，保證代碼質量等等。
代碼質量
如果你曾經試過忘記分號或者添加額外的逗號，那麼，你就知道將要在你的代碼中花費多長時間去發現這個微妙的錯誤。這就是為什麼你在運行代碼的時候需要通過一個像JSHint的工具，是吧？它是可配置的，而且有許多方法可以整合到你的代碼到你的編輯器或者創建到進程當中。
說明書
哎！除了MDN比較接近以外，好像沒有其他前端開發者說明書了。好的前端開發者知道在任何搜尋引擎上通過mdn查詢前綴，比如mdn javasrcipt 數組--為了防止像w3schools這樣的非盈利插件。
最後
不管怎樣，閱讀這些東西不會讓你變成一個專家或者厲害的技術--唯一可以確定使你變得更好的方法就是努力去學這些東西吧！
Good luck