Nodejs 有什么反模式吗？
Node.js 的反模式是什么，使用 Node 开发时应该避免什么.js？
GC、闭包、错误处理、OO 等危险。
What are the anti-patterns of node.js, what should you avoid when developing with node.js?
Dangers like GC, closure, error handling, OO and so on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
反模式：
同步执行：
我们避免所有同步执行，这也称为阻塞 IO。 Node.js 构建在非阻塞 IO 之上，任何单个阻塞调用都会立即引入瓶颈。
fs.renameSyncfs.truncateSyncfs.statSyncpath.existsSync都是阻塞 IO 调用，这些必须避免。
但它们确实存在是有原因的。它们可能且只能在服务器的设置阶段使用。在设置阶段使用同步调用非常有用，这样您就可以控制执行顺序，并且在处理第一个传入时，您不需要非常努力地考虑哪些回调已执行或尚未执行要求。
低估 V8：
V8 是 Node.js 构建的底层 JavaScript 解释器。 （是的，spidernode 正在开发中！）V8 速度很快，它的 GC 非常好，它确切地知道它在做什么。无需微观优化或低估 V8。
内存泄漏：
如果您来自强大的基于浏览器的 JavaScript 背景，那么您不会太关心内存泄漏，因为单个页面的生命周期从几秒钟到几个小时不等。单个 Node.js 服务器的生命周期从几天到几个月不等。
当您有非服务器端 JS 背景时，您不会考虑内存泄漏。深入了解内存泄漏非常重要。
一些资源：
目前我自己也不知道如何先发制人地防御它们。
JavaScript
JavaScript 的所有反模式都适用。在我看来，主要的破坏性是将 JavaScript 视为 C（仅编写过程代码）或 C#/Java（伪造经典继承）。
JavaScript 应该被视为一种典型的 OOP 语言或一种函数式语言。我个人建议您使用新的 ES5 功能，并使用 underscore 作为实用带。如果您充分利用这两者，您将自动开始以适合 JavaScript 的函数式风格编写代码。
我个人对如何编写正确的原型 OOP 代码没有任何好的建议，因为我从来没有掌握它的窍门。
模块化代码：
node.js 具有出色的
require语句，这意味着您可以模块化所有代码。Node.js 中不需要全局状态。实际上，您需要专门去
global.foo = ...来提升到全局状态，而这始终是一种反模式。一般来说，代码应该是弱耦合的，EventEmitter 允许对模块进行很好的解耦，并编写易于实现/替换的 API。
代码完整：
代码完整 2 书中的任何内容都适用，但我不会重复一遍。
Anti patterns:
Synchronous execution:
We avoid all synchronous execution, this is also known as blocking IO. node.js builds on top of non-blocking IO and any single blocking call will introduce an immediate bottleneck.
fs.renameSyncfs.truncateSyncfs.statSyncpath.existsSyncAre all blocking IO calls and these must be avoided.
They do exist for a reason though. They may and may only be used during the set up phase of your server. It is very useful to use synchronous calls during the set up phase so you can have control over the order of execution and you don't need to think very hard about what callbacks have or have not executed yet by the time you handle your first incoming request.
Underestimating V8:
V8 is the underlying JavaScript interpreter that node.js builds on. (Yes spidernode is in the works!) V8 is fast, it's GC is very good, it knows exactly what's it doing. There is no need to micro optimise or under estimate V8.
Memory Leaks:
If you come from a strong browser based JavaScript background then you don't care that much about memory leaks because the lifetime of a single page ranges from seconds to a few hours. Where as the lifetime of a single node.js server ranges from days to months.
Memory leaks is just not something you think about when you come from a non server-side JS background. It's very important to get a strong understanding of memory leaks.
Some resources:
Currently I myself don't know how to pre-emptively defend againts them.
JavaScript
All the anti-patterns of JavaScript apply. The main damaging ones in my opinion are treating JavaScript like C (writing only procedural code) or like C#/Java (faking classical inheritance).
JavaScript should be treated as a prototypical OOP langauge or as a functional language. I personally recommend you use the new ES5 features and also use underscore as an utility belt. If you use those two to their full advantage you'll automatically start writing your code in a functional style that is suited to JavaScript.
I personally don't have any good recommendation on how to write proper prototypical OOP code because I never got the hang of it.
Modular code:
node.js has the great
requirestatement, this means you can modularize all your code.There is no need for global state in node.js. Actually you need to specifically go
global.foo = ...to hoist into global state and this is always an anti-pattern.Generally code should be weakly coupled, EventEmitter's allow for great decoupling of your modules and for writing an easy to implement / replace API.
Code Complete:
Anything in the Code Complete 2 book applies and I won't repeat it.