工作上使用 Node.js 的 10 条经验
发布于 3 年前 作者 nswbmw 9001 次浏览 最后一次编辑是 6 个月前 来自 分享

1.精确版本号

“一定要精确到具体版本号!使用*直接滚,^和~都不行!”,早上刚到公司,我们服务器的头头满眼血丝(估计又凌晨几点睡的),对我抱怨道:“妈蛋,以前写的代码package.json里的版本和服务器正在运行的版本不一样。安装最新的又咣咣一顿报错。”此处省略几千字。。。

好吧。我先打自己脸。以前只会用*。。。大多时候也没必要写死版本号,使用^和~也可以。扫一下盲:

更严格点,可以使用 npm shrinkwrap 或者 yarn。

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上已经有38W的第三方模块了,理论上想用的都能在npm上找到,当然npm上不乏非常多的优秀的模块,文档全面,使用也非常方便,通常都会满足需求。假如你发现某个模块能满足大部分需求可以有功能上的完善,或有bug,可以去github上提pr,假如你发现没能找到满足的模块的话,可以自己创建个并npm publish到npm上与大家共享。尽量避免造轮子,因为时间是宝贵的。当然你发现某类实现某个功能的模块实在很shit的话,造个轮子那是必须的。

7.保持简单

假如你想展示一个饼图的话,用 HTML5 canvas 或 CSS3 即可,没必要用 C++ 的 canvas 库画一个图片,“光下载依赖的库就 400+ MB”,头头如是说。

8.良好的文档

良好的文档是客户端与服务器团队交流的最重要的渠道。文档写得明明白白了,假如客户端请求出错了,就可以先去查看文档(比如每个错误代码代表了什么),而不是每次出问题了就来找服务器的人讨论。PS: 一些 http 请求示例尽量用 curl 写,而不是 js 中的对象等的方式,也许你看的很懂,但客户端的人不懂 js。

9.配置文件

在每个工程目录下都建一个配置文件,如 config.js/config.json。而不是写死在代码里。如:

{
  "app": 3000,
  "mongo": {
    "host": "localhost",
    "port": 27017
  },
  "redis": {
    "host": "localhost",
    "port": 6379
  }
  ...
}

10.使用 pm2

使用 pm2 等这种进程管理工具,很方便,最不济进程挂掉了还能自动重启吶。没用过 forever 不做评价。。还有 grunt 神马的也没用过,不做评价。

51 回复

前人的经验也是一种指导~ 收藏

顶一下、

好东西, 帮顶

  1. 再多推荐一个测试框架: sinon
  2. 你们头头蛮神秘的嘛 哈哈

赞“头头”

感谢楼主的分享,社区就是需要更多这样的,才会让node越来越火!

感谢分享宝贵的经验,+1

@yorkie =。=

小星星你终于闭关修炼结束了,恭喜出关~

用心写了这么多,赞!

谢谢了, FYI, 发现这个被转了 http://codecloud.net/node-js-2-2202.html

再看之前写的版本管理的文章,里面有些东西又过时了,今天去 update 一下…

多么痛的领悟!

@dead-horse 看来我起了督促的作用。。

@snoopy 还早呢。。

@nswbmw 哈哈, semver 和 npm 太坑, 已更新…

我自己做这么久的Noder,可能和LZ不一样,我是older fe’s noder,开始的时候确实对服务并发不是很在意,最开始的一次,流量一上来直接服务就挂了,pm2这种也算最基本的了。 真正开发久了,自然也就会关注并发,服务监控、内存优化等方面

第 9 条 配置文件,我推荐使用 config.js 而不是 .json,更灵活。

你说的这个debug模块不会用啊,在代码里面加了debug,但是启动之后调试信息都没打出来啊?

@arden DEBUG=* node app

这命令是要在linux下运行?我的是windows

真正开发久了,自然也就会关注并发,服务监控、内存优化等方面 现在对nodejs的性能优化完全没谱,资料也很少,用nodejs有时候真的很担心这方面的问题。

@arden

set debug=*
node app

@arden 我咋感觉第一句话和我上面说的一模一样呢?

多么痛的领悟!

pm2也并不是想的那么好,等你用久了你会发现它有致命的bug

* 原来是任意,这坑太大了…

入门容易提高难啊

@alsotang 使用config.js是为了定义一些函数?感觉config是为了定义一些运行时候的参数,为什么要放一些函数在这里(如果用.js是为了定义函数的话)?

用上bearcat,运维开发会好很多

@gitchs 用 js 也不是光是为了定义函数,但其实也是希望 config.js 在被引入的时候,可以执行一些代码逻辑。

@alsotang -1 那样是module 不是配置模块啦 使用config.json的最大的好处是一份配置文件,跨平台使用,否则在c/c++环境下需要加载一个libv8了

@yorkie 我觉得跨平台的配置文件是个大误解,有什么项目的配置文件不是项目专用的呢?

@alsotang db的host/port/user/pass 这些都会是可以被很多应用使用的,因为数据库和各种native交互的过程本身就是靠协议走,而不是api 我现在的工作往往是一(n)个db会给很多客户交付,但是因为客户要求不同,往往会根据业务、要求本身选择合适的平台,因为客户多、配置文件多,所以不喜欢配置文件冗余,就是这样子的。 -1的另一个理由:json是协议是标准,js只是一个运行时,我更喜欢协议

@yorkie 嗯嗯,你这个场景还是比较适合用 json 这类通用格式的。

@dreamdyj 你挖了个坟就为了回复一个“顶”。。。。。

PM2 有些过了,个人理念是小而精,不喜欢大而全,并且 PM2 坑有点多

@alsotang 还有JS,可以添加注释,@yorkie 的这种情况走协议更好

对于第一条,请用 yarn ,有yarn.lock文件帮你锁定版本号。 第七条使用 400M+ 的C++依赖也是醉了,赞头头。

node什么支持多线程

@sarike 两年前的贴,那时还没有 yarn

另外提醒一下大家,如果用的 npm,即使全部指定的是精确的版本号,仍然会有问题。因为你无法保证你依赖的包的 package.json 中都是精确版本号。 必须用用 npm-shrinkwrap 或者 yarn

2年前的帖子!

回到顶部