我想改進我的Coffeescript編碼風格。當我在Scala編程時，我可以在一兩個小時內編寫一個模塊，運行它，並且只有一些我可以快速識別和修復的小錯誤。如何提高Coffeescript的生產率？
在Coffeescript中，我花了大約相同的時間在前面，但最終導致大量的小錯誤被靜態類型檢查器捕獲，最終我不得不編譯，重載瀏覽器，逐步完成一些代碼，添加一些斷點等。這是一種真氣體驗，需要更長的時間。
由於缺乏接口和許多其他的OO特性，抽象和封裝功能要困難得多。
是否有設計模式取代OO一般提供的封裝/抽象？或者是否有關於如何以更多Coffeescript-y方式思考的引言/指南（或者如何使用原型方法解決問題）？
你在Coffeescript（或Javascript--甚至可能是任何動態類型的語言）中做了哪些工作以提高生產力？
如果您來自Java或Scala等靜態類型的以類爲中心的語言，那麼學習JavaScript/CoffeeScript將會是一個挑戰。編譯器幾乎沒有幫助你，這意味着需要幾分鐘才能發現小錯誤而不是秒。
如果這是你的主要瓶頸，那麼我建議擁抱更多的測試驅動編碼方法。使用像QUnit這樣的庫爲您開發的每一項功能編寫小測試。如果使用得當，這種風格爲您提供與靜態編譯器相同的好處，而不會影響動態語言的靈活性。
+1用於提示測試驅動方法。 –
可悲的是，沒有多少人測試JavaScript，因爲歷史上這些工具並不是太好。現在有很多很棒的工具，例如QUnit和[Mocha]（http://visionmedia.github.io/mocha/），這些工具使JavaScript測試變得簡單而有趣。 – Andrew
不要直接去Coffee Script。從原型和Javascript OO學習核心概念。 IMMO您可以同時學習，但如果您先獲得Vanilla Javascript，您將受益匪淺。根據我的個人經驗，如果您不瞭解原型繼承（容易陷入錯誤），Coffee Script語法糖類可能會成爲陷阱。
咖啡腳本調試在工具方面仍然不是一個完全解決的問題，我唯一知道的方法就是編寫測試（當你剛開始的時候很痛苦）或者看看生成的代碼（在至少對於更晦澀的錯誤）。
再次 - 我瞭解Javascript和原型繼承（我不完全是Coffeescript的初學者）。 更多的是，我沒有用原型語言來解決問題的方法的工具帶（我可以很快設想出一個經典的oo解決方案）。 同樣，它更多的是我犯了簡單的錯誤，無論是編譯器還是我的IDE通常都會捕獲 - 或者由於類型簽名而清楚。例如，是否存在將類型編碼到函數簽名中的標準/好方法（或者甚至是將它們編入文檔的標準方式）？ – laurencer
對我來說也很奇怪;在我的情況下來自C/C++的背景。
單擊我的是，只需稍微調整一下工作環境，就可以顯着縮短迭代時間。這個想法是足夠減少它，你可以用小塊編寫代碼並且非常頻繁地測試你的代碼。
缺乏編譯時間檢查：你會習慣它。像重要的白色空間一樣，編譯時類型檢查的缺乏在幾周後就會消失。很難說如何，但至少我可以告訴你，它確實發生在我身上。
由於缺乏接口：這是一個棘手的問題。如果在更大的系統中獲得更多的幫助以提醒您實現整個界面，那將是非常好的。如果你發現你真的失去了很多時間，你可以編寫自己的運行時檢查，並在適當的地方插入它們。例如。如果您向中央管理人員註冊您的對象，那麼確保對象符合提交給他們的角色是一個好時機。
總的來說，記住你有體面的反射能力是很好的。
關於缺少封裝：鑑於coffeescript實現了一個非常好的類包裝到原型方案，我假設你的意思是缺乏私有變量？實際上，您可以通過多種方式隱藏客戶的詳細信息，如果您覺得有必要，我也可以;通常是爲了阻止自己未來的腳步。關鍵是通常在關閉時將東西松開。
另外，看看Object.__defineGetter__/Object.defineProperty?吸氣劑和二道助手可以在這些情況下幫助很多。
在減少迭代時間：
我用的是內置的文件裏的守望者咖啡彙編關於變化的腳本。再加上TextMate在失去焦點時保存所有打開文件的能力，這意味着測試是從textmate切換到chrome/firefox並刷新的問題。蠻快。
雖然在node.js項目中，我已經設置了我的視圖，以便即時編譯和提供服務，所以即使文件監視器也是多餘的。它們被緩存在發行版中，但在調試模式下，它們總是從磁盤重新加載，重新編譯，遇到錯誤時我只需提供它們。所以現在每隔幾分鐘我切換到瀏覽器，刷新並看到我的測試運行或編譯器錯誤。
這不是一個答案，但要在咖啡標記中發揮作用，你必須非常熟悉Javascript。如果你不是，調試體驗可能真的很痛苦。 –
我對JavaScript和Coffeescript都很熟悉 - 我可以根據應用程序行爲識別錯誤，並且我瞭解Javascript的大部分奇怪部分。 更多的是我一直在犯同樣的錯誤/錯誤，我不會用靜態類型的語言。我不知道採用特定的編碼風格是否會有所幫助（這使得類型更清晰，並且使得更簡單的拼寫錯誤和類型錯誤變得更難） - 但是現在我不能相信這不是別人已經有的東西瞭解決了。 – laurencer
使用動態語言時，自動化測試是至關重要的。擁有一個好的測試套件對於在潛在地改變應用程序時捕獲錯誤非常有幫助。 – Andrew