先不说房价，堵车，雾霾。。。先说说我这半年使用 Node.js 的经验吧。。。都是工作上遇到的问题，血的教训。。
1.精确版本号
“一定要精确到具体版本号！使用*直接滚，^和~都不行！”，早上刚到公司，我们服务器的头头满眼血丝（估计又凌晨几点睡的），对我抱怨道：“妈蛋，以前写的代码package.json里的版本和服务器正在运行的版本不一样。安装最新的又咣咣一顿报错。”此处省略几千字。。。
好吧。我先打自己脸。以前只会用*。。。大多时候也没必要写死版本号，使用^和~也可以。扫一下盲：
semver
node.js 中的版本管理
2.测试
一定要写测试用例。就拿我来说，我负责的那块包含过滤部分（用正则神马的过滤文本，提取出有用的文本）。有了测试用例，每次改动过滤规则后，npm test 下，妥妥的。依个人喜好挑选使用的测试模块，mocha, should, tape, tap, supertest 等等。
尝试本地运行，测试成功后才上传到服务器。我好几次改完代码（就简单的改了几行）以为怎么可能会出问题，结果一重启服务器就挂了。。尼玛少了括号什么的。。这种问题也可以通过使用jslint或jshint等编辑器插件来检测低级语法错误。
服务器代码备份。目前我使用的方法：起初服务器上有两个一模一样的工程（git库，文件名不一样），一个正在运行，另一个当作备份。当有代码改动时，到备份工程下 git pull ，然后停止正在运行的程序，启动备份的程序。假如程序经过一段时间没有挂掉也就是感觉比较稳定后，将此工程当作主，另一个工程当作备。当又有改动时，重复以上步骤，主备来回切换。假如程序挂掉了，则切换回较稳定的备即可。
3.使用 debug
写程序免不了调试，很多人喜欢并习惯用万能的 console.log() ，包括我。。就个人而言，我使用 console.log() 调完后，不是删掉就是注释掉。删掉吧以后也许还会用到，注释掉吧怪难看。这个时候不妨用用 debug 模块。暂时没用过 node-inspector，不做评价。
4.保持代码精简
尝试用较少的代码完成较多的事情，也是对自己能力的提升与考验。包括正确的缩进，恰当的变量名，清晰的代码组织结构等等。。代码精简了，漂亮了，当出问题了回头查错也快，总比先弄明白一团乱糟的代码干了些什么就花了几个小时强。
假如团队没有使用CoffeeScript的话就不要使用它。一是别人无法读懂你的代码帮你纠错。二是出错后显示出错的行数和coffee代码的行数不一样。。。自己的开源项目可以用用。
5.多请教，保持独立思考
刚开始工作的时候，我也各种一头雾水，包括技术上的不足和业务逻辑上的欠缺，常常请教团队内的大牛。而后我会尝试弥补技术上的不足，理清业务上的逻辑。后来有一次，我要根据 PM 的要求设计一个 api，既要考虑用户的需求（多客户端的情况），客户端的需求和行为，数据库的设计（怎么存冗余少，查询次数少，易扩展，易修改，差量查询）等等，考虑了一个周多，几近崩溃。。。虽然我和头头商量了好多次，但它总是给我理逻辑，不告诉我方法。后来终于找了一种还算不错的解决方式。。他后来也告诉我，想让我保持独立思考去解决问题，这样才能有提高。。
6.使用现有的库
目前npm上已经有近9W的第三方模块了，理论上想用的都能在npm上找到，当然npm上不乏非常多的优秀的模块，文档全面，使用也非常方便，通常都会满足需求。假如你发现某个模块能满足大部分需求可以有功能上的完善，或有bug，可以去github上提pr，假如你发现没能找到满足的模块的话，可以自己创建个并npm publish到npm上与大家共享。当然你发现某类实现某个功能的模块都很shit的话，你也可以publish个不shit的。
7.保持简单
假如你想展示一个饼图的话，用 HTML5 canvas 或 CSS3 即可，没必要用 C++ 的 canvas 库画一个图片，“光下载依赖的库就 400+ MB”，头头如是说。
8.良好的文档
良好的文档是客户端与服务器团队交流的最重要的渠道。文档写得明明白白了，假如客户端请求出错了，就可以先去查看文档（比如每个错误代码代表了什么），而不是每次出问题了就来找服务器的人讨论。PS: 一些 http 请求示例尽量用 curl 写，而不是 js 中的对象等的方式，也许你看的很懂，但客户端的人不懂 js。
9.配置文件
在每个工程目录下都建一个配置文件，如 config.js/config.json。而不是写死在代码里。如：