如何提高 Coffeescript 的工作效率？
我想改进我的 Coffeescript 编码风格。当我用 Scala 编程时，我可以在一两个小时内编写一个模块，运行它，并且只有一些小错误，我可以快速识别和修复。
在 Coffeescript 中，我预先花费了大约相同的时间，但最终遇到了数量惊人的小错误，这些错误可能会被静态类型检查器捕获，并且我最终不得不编译，重新加载浏览器，单步执行一些代码，添加这是一次令人恼火的经历，并且需要更长的时间。
由于缺乏接口和许多其他面向对象的功能，抽象和封装功能要困难得多。
是否有设计模式可以替代 OO 通常提供的封装/抽象？或者是否有关于如何以更 Coffeescript 风格的方式思考（或如何使用原型方法解决问题）的入门/指南？
您做了什么来提高 Coffeescript（或 Javascript - 甚至可能是任何动态类型语言）的工作效率？
I want to improve my Coffeescript coding style. When I program in Scala, I can write a module in an hour or two, run it and have only a few minor bugs that I can quickly identify and fix.
In Coffeescript, I spend about the same time up front but I end up having a staggering amount of small bugs that would have been caught by a static type checker and I end up having to compile, reload the browser, step through some code, add some break points, etc. It's an infuriating experience and takes significantly longer.
It's much harder to abstract and encapsulate functionality due to the lack of interfaces and many other OO-features.
Are there design patterns that replace the encapsulation/abstraction generally provided by OO? Or is there a primer/guide on how to think in a more Coffeescript-y way (or how to solve problems using a prototypical approach)?
What have you done to become more productive in Coffeescript (or Javascript - perhaps even any dynamically typed languages)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您来自 Java 或 Scala 等静态类型、以类为中心的语言，那么学习 JavaScript/CoffeeScript 将是一个挑战。编译器对您的帮助几乎没有那么大，这意味着您需要几分钟而不是几秒钟才能发现小错误。
如果这是您的主要瓶颈，那么我建议采用更加测试驱动的编码方法。使用像 QUnit 这样的库为您开发的每项功能编写小型测试。如果使用得当，这种风格可以为您提供与静态编译器相同的好处，而不会影响动态语言的灵活性。
If you're coming from a statically-typed, class-centric language like Java or Scala, learning JavaScript/CoffeeScript is going to be a challenge. The compiler doesn't help you nearly as much, which means that it takes you minutes to discover small mistakes instead of seconds.
If that's your major bottleneck, then I'd suggest embracing a more test-driven coding methodology. Use a library like QUnit to write small tests for each piece of functionality you develop. Used properly, this style gives you the same benefits as a static compiler without compromising the flexibility of a dynamic language.
不要直接进入咖啡脚本。从原型和 Javascript OO 中学习核心概念。 IMMO 你可以同时学习两者，但如果你先学习 Vanilla Javascript，你会受益更多。根据我个人的经验，如果您不了解原型继承，那么类的 Coffee Script 语法糖可能是一个陷阱（很容易陷入错误）。
就工具而言，咖啡脚本调试仍然不是一个完全解决的问题，我知道可以完成的唯一方法是编写测试（刚开始时很痛苦）或查看生成的代码（至少对于更多隐藏的错误）。
Don't go straight to Coffee Script. Learn the core concepts from prototype and Javascript OO. IMMO You can learn both at the same time, but you will benefit much more if you get Vanilla Javascript first. Based on my personal experience, Coffee Script syntactic sugar for classes can be a trap if you don't understand prototypical inheritances (it's easy to get stuck on a bug).
Coffee Script debugging is still not a completely solved matter in terms of tools, the only way I know it can be done is to write tests (a pain when you're just starting) or look at the generated code (at least for the more obscure bugs).
这对我来说也很奇怪。就我而言，我有 C/C++ 背景。
让我印象深刻的是，通过对工作环境进行一些调整，您可以显着减少迭代时间。我们的想法是充分减少它，以便您可以以小块的形式编写代码并非常频繁地测试您的代码。
关于缺乏编译时检查：您会习惯的。就像大量的空白一样，编译时类型检查的缺乏在几周后就会消失。很难说到底是怎么回事，但至少我可以告诉你，这确实发生在我身上。
缺乏接口：这是一个棘手的问题。如果能在大型系统中获得更多帮助来提醒您实现整个接口，那就太好了。如果您发现确实为此浪费了很多时间，您可以编写自己的运行时检查，并在适当的地方插入它们。例如，如果您向中央管理器注册对象，那么这将是确保对象符合它们所提交到的角色的好时机。
一般来说，最好记住您拥有良好的反思能力。
关于缺乏封装：考虑到 CoffeeScript 为原型方案实现了一个非常好的类包装器，我假设您的意思是缺乏私有变量？实际上，如果您觉得有必要，可以通过多种方式向客户隐藏详细信息，而我就是这么做的；通常是为了阻止自己将来开枪。关键通常是将东西存放在闭包中。
另外，看看
Object.__defineGetter__/Object.defineProperty?Getter 和 setter 在这些情况下可以提供很大帮助。关于减少迭代时间：
我使用咖啡中内置的文件观察器来编译更改时的脚本。再加上 TextMate 能够在失去焦点时保存所有打开的文件，这意味着测试只需从 textmate 切换到 chrome/firefox 并点击刷新即可。相当快。
不过，在 Node.js 项目中，我已将视图设置为动态编译和服务，因此即使文件观察器也是多余的。它们在发布时被缓存，但在调试模式下，它们总是从磁盘重新加载、重新编译，并且在遇到错误时我只是提供它们。所以现在每隔几分钟我就会切换到浏览器，点击刷新，要么看到我的测试正在运行，要么看到编译器错误。
It was odd for me too; in my case coming from a C/C++ background.
What clicked for me is that you can reduce your iteration time significantly with a few tweaks of your work environment. The idea is to reduce it enough that you can write code in small chunks and test your code very very frequently.
On the lack of compile time checks: You'll get used to it. Like significant white space, the lack of compile time type checking just melts away after a few weeks. It's hard to say how exactly, but at least I can tell you that it did happen for me.
On the lack of interfaces: that's a tricky one. It would be nice to get a little more help in larger systems to remind you to implement entire interfaces. If you're finding that you really are losing a lot of time to that, you could write your own run time checks, and insert them where appropriate. E.g. if you register your objects with a central manager, that would be a good time to ensure that the objects qualify for the role they're being submitted to.
In general, it's a good to bear in mind that you have decent reflection abilities to hand.
On the lack of encapsulation: Given that coffeescript implements a very nice class wrapper to the prototype scheme, I'm assuming you mean the lack of private variables? There are actually a number of ways you can hide details from clients, if you feel the need to, and I do; usually to stop myself from shooting my foot in the future. The key is usually to squirrel things away in closures.
Also, have a look at
Object.__defineGetter__/Object.defineProperty?Getters and setter can help a lot in these situations.On reducing iteration time:
I was using the built in file watcher in coffee to compile the scripts on change. Coupled with TextMate's ability to save all open files on losing focus, this meant that testing was a matter of switching from textmate to chrome/firefox and hitting refresh. Quite fast.
On a node.js project though, I've setup my views to just compile and serve on the fly so even the file watcher is superfluous. They're cached in release, but in the debug mode they're always reloaded from disk, recompiled, and on encountering errors I just serve them up instead. So now every few minutes I switch to the browser, hit refresh and either see my test running, or the compiler errors.