10经验总结了Node.js半年
不是说房价，交通拥堵，雾霾，让我在今年上半年的Node.js经验谈。这是所有工作中的问题，血的教训。1。精确的版本号
必须精确到特定版本号！使用*直接滚动，和不！在早上，当我们第一次来到公司，我们的服务器的头上全是血（据估计在早上同样的睡眠时间），并向我抱怨，妈蛋，版本以前编写的代码package.json不同版本的服务器正在运行。安装最新的和棒棒一报错。几千字在这里省略了。
好的，我先打了我的脸，原来是*。大多数时候，不需要写一个死的版本号，也可以用~和~：
semver
在Node.js版本管理
2。测试
请务必编写测试用例。对于我来说，我负责的部分包含过滤部分（使用普通马的过滤文本来提取有用的文本）。的过滤规则改变后，在故宫测试是正确的。根据个人喜好，摩卡，选择使用的测试模块、磁带、龙头、测等。
尝试本地操作并在测试成功后将其上传到服务器。我已经多次更改代码（只需几行），并认为这可能是个问题。因此，服务器挂了就马上启动。Nima失踪的括号中。这个问题可以通过使用编辑器插件如JSLint或jshint低级语法错误检测。
服务器代码备份。目前，我使用的方法是：首先，服务器上有两个相同的项目（Git库，文件名称是不同的），一个是跑步和其他备份。当有一个变化的代码，git pull去备份的项目，然后停止运行程序和启动备份程序。如果程序没有被挂了一段时间，就是感觉更稳定，该项目被视为主人，另一个是作为制备。当有另一个变化，重复以上步骤，如果来回切换。程序被挂起，切换到一个更稳定的制备。
三.使用调试
写程序不能帮助调试，很多人喜欢使用通用console.log（），包括我在内。就我个人而言，我使用console.log（）调出来，不删除它或对它进行注释。删除以后可能有用，注释出了奇怪的表情。你也可以使用调试在这time.node-inspector模块不使用时，并没有进行评价。
4。保持代码的简化
尽量少用代码做更多的事情，也能提高你的能力测试，包括正确的压痕，适当的变量的名字，清晰的组织代码，等等。代码是流线型的，美丽的，当它涉及到的问题，它的速度在错误的道路上回头看比找出什么乱七八糟的代码已经过了几个小时做。
如果团队不使用Coffeeｓｃｒｉｐｔ，不要使用它。一是别人无法读懂你的代码来帮助你改正它。二是错误之后的行显示错误的数量，在咖啡的代码行数。自己的开源项目可以使用。
超过5。咨询，保持独立思考
我刚开始工作的时候，各种损失，包括业务逻辑的不足和技术团队，经常问丹尼尔。然后我会设法弥补技术上的不足和明确的业务逻辑。有一天，我将设计一个API根据项目的要求，有必要考虑用户的需求（多客户端的情况），客户的需求和行为，数据库设计（如何保存较少的冗余查询号码，易扩展，易修改、易鉴别查询）等，考虑一个星期，几近崩溃…虽然我已经咨询了很多次，我的头，它总是给我的逻辑不告诉我怎么做。最后，一个好的解决方案，终于找到了。他后来告诉我说，我想保持思想独立地来解决问题，这样我可以提高。
6。使用现有的库
目前，有近第三方模块在NPM在9W，可以发现NPM理论。当然，有许多优秀的模块管理。该文件是全面和方便使用，通常满足需要。如果你发现一个模块可以满足大部分的需求，你可以有功能上的改进，或者bug，你可以去GitHub上拿起问题如果你发现你找不到你想遇到的模块，你可以创建你自己的NPM发布并与你分享。当然，你发现一个类实现的功能模块很屎，你也可以发布不拉屎。
7。保持简单
如果你想显示一个饼图，如果你使用HTML5的canvas或CSS3，你不需要用C++库的帆布画一幅画，和400 + MB下载相关的库。
8。好的文件
良好的文档是客户机和服务器团队之间最重要的沟通渠道。如果客户端请求是错误的，你可以先看文件为例，每个错误代码表示，而不是人来的服务器只要有problem.ps：一些HTTP请求的例子都写在曲尽可能不在对象的JS的方式，也许你明白，但是客户不懂js。
9。配置文件
在每个项目目录，配置文件，如配置。js / json，是建立。而不是写的代码，如：
{
应用程序：3000，
芒果：{
主持人：localhost
端口：27017
}，
红：{
主持人：localhost
端口：6379
}
…
}
10。使用PM2
如PM2非常方便这样的流程管理工具的使用，和最困难的过程可以自动重启。不要用永远不做评价。和咕噜不使用，不做评价。