从3月初来到帝都某创业公司的服务器团队实习,到现在已接近半年的时间。PS: 已转正,服务器端用的 Node。
先不说房价,堵车,雾霾。。。先说说我这半年使用 Node.js 的经验吧。。。都是工作上遇到的问题,血的教训。。
1.精确版本号
“一定要精确到具体版本号!使用*直接滚,^和~都不行!”,早上刚到公司,我们服务器的头头满眼血丝(估计又凌晨几点睡的),对我抱怨道:“妈蛋,以前写的代码package.json里的版本和服务器正在运行的版本不一样。安装最新的又咣咣一顿报错。”此处省略几千字。。。
好吧。我先打自己脸。以前只会用*。。。大多时候也没必要写死版本号,使用^和~也可以。扫一下盲:
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。而不是写死在代码里。如:
{
"app": 3000,
"mongo": {
"host": "localhost",
"port": 27017
},
"redis": {
"host": "localhost",
"port": 6379
}
...
}
10.使用 pm2
使用 pm2 等这种进程管理工具,很方便,最不济进程挂掉了还能自动重启吶。没用过 forever 不做评价。。还有 grunt 神马的也没用过,不做评价。
我自己做这么久的Noder,可能和LZ不一样,我是older fe’s noder,开始的时候确实对服务并发不是很在意,最开始的一次,流量一上来直接服务就挂了,pm2这种也算最基本的了。 真正开发久了,自然也就会关注并发,服务监控、内存优化等方面
@alsotang db的host/port/user/pass 这些都会是可以被很多应用使用的,因为数据库和各种native交互的过程本身就是靠协议走,而不是api 我现在的工作往往是一(n)个db会给很多客户交付,但是因为客户要求不同,往往会根据业务、要求本身选择合适的平台,因为客户多、配置文件多,所以不喜欢配置文件冗余,就是这样子的。 -1的另一个理由:json是协议是标准,js只是一个运行时,我更喜欢协议