TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Node.js: Am I just doing it wrong?

18 点作者 farmdawgnation超过 11 年前

4 条评论

ricardobeat超过 11 年前
All fair points, these are issues faced by almost everyone starting a node project. Here is a set of good practices that might help:<p>1. Use dependency injection moderately. require() calls are cached, and you can overwrite modules for testing with proxyquire&#x2F;rewire. If you are using mongoose, for example, you don&#x27;t need to throw around a db instance, just require(&#x27;mongoose&#x27;) on each module and access models with mongoose.model(&#x27;User&#x27;).<p>2. Separate route definitions from controllers:<p><pre><code> &#x2F;&#x2F; tree.js exports.getNuts = function (req, res) { ... } &#x2F;&#x2F; routes.js var tree = require(&#x27;.&#x2F;controllers&#x2F;tree.js&#x27;) app.get(&#x27;&#x2F;nuts&#x27;, tree.getNuts) </code></pre> 3. Keep your controllers lean and move logic to your Models or a separate concerns&#x2F;lib layer, so you can re-use these methods within the application.<p>4. Use a control-flow library like async, queue-async, etc. I wouldn&#x27;t recommend promises as a first since they come with their own caveats. Break down logic into many small methods instead of huge chains.<p>5. Absolutely, whenever possible, break out helper methods, abstractions and common patterns in your code into separate npm modules, with it&#x27;s own set of tests. This should be the final fate of everything in the &#x2F;lib directory, if you have one. Doing this helps keep your codebase lean and focused, and is a good opportunity to give back to the community.<p>A rough suggestion on how to organize that last module.exports using caolan&#x2F;async: <a href="https://gist.github.com/anonymous/7062240" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;anonymous&#x2F;7062240</a><p>Finally, it&#x27;s nice to use a database driver that buffers commands before connect, so you don&#x27;t need an async step on app initialization.
评论 #6578357 未加载
hackula1超过 11 年前
A couple suggestions:<p>callback hell -- 1) Define your callback functions instead of passing anonymous functions everywhere. 2) Use a control flow library like async. <a href="https://npmjs.org/package/async" rel="nofollow">https:&#x2F;&#x2F;npmjs.org&#x2F;package&#x2F;async</a> This will greatly help in complex scenarios and the &quot;waterfall&quot; mode is particularly useful to accomplish something similar to chaining where values flow through multiple functions. Callback hell is not really an issue for most people after looking into these two things.<p>data manipulation -- <a href="https://npmjs.org/package/lodash" rel="nofollow">https:&#x2F;&#x2F;npmjs.org&#x2F;package&#x2F;lodash</a> lodash is a fast functional utility library that makes it much easier to do the everyday data manipulation tasks. I pretty much assume this will be a dependency whenever I start a non-trivial project now.<p>lack of standards -- Most people who really like node.js see this as a feature not a bug. This definitely drives away many people, but the intention is to promote as much choice as possible. Node.js people tend to be obsessed with choice and modularity. This is not meant as &quot;you should think this way too&quot; type explanation, but just a rough description of how the community is, good or bad. That being said, there are some standards out there. For example Felix&#x27;s style guide is followed pretty well throughout the community (with a couple notable exceptions such as some of TJ Holowaychuk&#x27;s stuff) <a href="http://nodeguide.com/style.html" rel="nofollow">http:&#x2F;&#x2F;nodeguide.com&#x2F;style.html</a>.<p>mocha output -- It appears you have your reporter option set to &quot;spec&quot;. This is a great reporter for visualizing a set of features, but for integration with something like Jenkins, I would recommend &quot;tap&quot; instead. It is also pretty trivial to write your own reporter, and then you can get whatever type of output you want. <a href="https://github.com/visionmedia/mocha/wiki/Third-party-reporters" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;visionmedia&#x2F;mocha&#x2F;wiki&#x2F;Third-party-report...</a><p>mocha integration testing -- I agree that the example you showed was more of an integration test than a unit test. Mocha is not really doing anything to discourage unit testing though, and I would note that integration tests can be valuable. If it were me, I would tend to have my unit tests working against the actual module, instead of an endpoint, which is kind of sloppy.<p>I hope that helps though :) I know it is often frustrating coming into a new language ecosystem, especially a &quot;friendly-anarchy&quot; oriented one like node.js.
ctvo超过 11 年前
I definitely relate with the author. I started my own node.js project last week.<p>I have no idea how to organize my Express app, I have no idea what asset manager to use and yesterday I spent 4 hours just tinkering with my gruntfile to get concat and copy tasks right so my front-end files get moved to the proper folders when I&#x27;m ready to build. This is all due to my ignorance &#x2F; lack of experience, but man, some readily available best practices would be really helpful.
评论 #6577689 未加载
评论 #6577718 未加载
EasyJoe超过 11 年前
See that light gray text on white background? THat means yes, you&#x27;re doing it wrong.<p>I can speak more about node.js once I can read your blog without discomfort.