[转载]Node.js之绝对选择 - 玄歌 - 博客园

[转载]Node.js之绝对选择 – 玄歌 – 博客园.

几年前,完全放弃ASP.NET,彻底脱离微软方向。Web开发,在公司团队中,一概使用Node.js、Mongodb、Git,替换ASP.NET mvc、SQL server和Tfs。当时来看,这是高风险的决定。所有人都习惯了ASP.NET,知识和技术积累也集中在这个方向。

表面看来,仅仅是我个人对多年跟从微软的厌烦,导致整个技术路线嘎然而止,从技术角度而言,团队由此南辕北辙。几年过去,各种辛苦和折腾,间或的彼此抱怨 之后,我们终于天经地义的,习惯了新的方向,没有人再有回到Asp.net的意思,恍若隔世,但…一定要比较,今天显然更为轻松。

当然,最初并非一切顺畅,每个选择,每一方都是王婆婆,她的瓜绝对是举世无双滴。面对诸多王婆的时候,我们也很难得到客观的比较,选择往往需要自己来做。 经过两个项目,才真正让一切顺畅起来。其中所涉的编程方式、各类细节甚至由此引发的不同设计思维,很明显经历了多处的反复。这个没有办法,node.js 相对较新,大规模在一些公司应用的情形并不多,这类文字当然也稀少,我们很难找到其他人归纳的常规的团队开发模式。

我简单的描述一下,对于以Node.js为主的公司,嗯,仅仅局限于中小型公司…或许有一定的帮助,少走些弯路。我们最终的选择是

1、IDE:Webstorm,没有其他。

2、版本管理系统:Git,独一无二。

3、单元测试:jsamine,前后端共用。

4、前端框架:Angular.js,让ember.js和几个老牌的框架性感的躺在床上吧。

5、服务端:纯静态页面+极少使用Jade+REST

6、socket.io+独立小模块:当然,这几乎是唯一可选的与客户端双向通信的方式。但一定要注意,多数情形下,我们只有很少的机会需要服务端推送,将这部分内容作为独立的小应用,是非常省事的做法。

7、异步流程控制:Promise是唯一选择,而且从一开始就要强制使用,绝不可忽略,这关系到设计思维的巨大差异,甚至关系到我们是否真正能够在 node.js方向坚持下来。我们用Q.js,和前端Angular.js使用的微缩版Q.js保持一致,减少学习周期。

8、前后端共用代码:只要前端有可能用到的代码,必须以符合规范的方式,做到前后端共用。

 

我知道多数的多数的,还是多数的技术文章,说话都是不极端的、中庸的,在肯定一到两个选择的时候,也会认同其他的选择,嗯,这固然是很成熟的文风,很厚道的人格。我呢,只会极端的就每个选择给出唯一的答案。

不是因为我性情不成熟,嗯,好歹我也算是超级资深的架构师、高级程序员、过程管理大半个专家…啊,还有没有其他的光环和帽子可戴?

既然我们在集中选择中左右碰撞后,得出了结论,我们的选择就是唯一的…多数情况下,您看到这篇随手的文字,就不再需要将这个痛苦的过程,重复一遍。我 觉的这是真正的厚道…那么多客气干嘛?噢,这可能有点”你们不用思考,元首都帮你们思考过了”的意思,这点不好…我在下面将几种主要选择的理由, 列出来…以避免从天而降的、聚合成团队的板砖。

一、IDE的选择:WebStorm

我们最初遇到的问题,是语言,C#转到js。 当然,这个事实上不是太大的问题,Asp.net方向的团队,基本上每个人都有相关语法知识。尤其开心的 是,node.js,在后端开发,不需要如前端开发一般,考虑浏览器差异。最初大家的共识是很简单的思维:js+node系统库+诸多可选的 包=C#+.net framework。额,当然,整个node.js占据的空间大约只有十来兆,IIS和.net framework加起来是多少?几十倍的体积差别,即使两者旗鼓相当,是不是该鄙视下,那过于吝啬硬盘的一方?

当然,要开始,第一个问题是IDE。最初,我一个人左右折腾,使用Visual studio+iisnode+Tfs,各种不便。1周后转到Webmetrix,3天后灰溜溜的放弃。然后各种ide象流水般的试试…WebStorm最初也被排斥。

在一个月黑风高的深夜,一双迷茫的眼睛,盯着天花板。

我重新捡起WebStorm,更精细的一步步尝试它所宣称的各类特性。语法自动感知、node.js的调试、Git集成、单元测试框架的集成….

嗯,一切之外的选择变成了浮云。

 

二、版本管理系统:Git

选择Git,最初是因为Tfs不再可用,我们已经告别了伟大的Visual Studio 20XX。那么…风评最好的,显然是Git,GitHub已经成长到让其他的开源社区瞠目结舌的地步,甚至Tfs也不得不支持Git。这不免太庸俗: 人人一边倒的说一个东西好,这东西就是好。

但是,但是那个但是…这东西用起来比Tfs麻烦许多噢,我们都不算是喜欢一个个敲命令的人吧?我本人率先使用,然后培训其他人,先行的过程虽然持续三天…但是:

1、分布式确实是最人性的做法:不再需要家中和公司服务器同步来同步去,不在同一城市也不再是问题。

2、分支成为主要的思维…前提是合并、冲突惊人的简易。

3、最为欣喜的是,结合WebStorm,几乎达到了VS中使用Tfs的效果,我们已经有几年不再手工输入命令了。

那么,你还需要考虑别的?

 

三、单元测试:Jasmine

这个选择,纯粹是由于我天生的懒惰。 前端Angular.js,单元测试用karma…jasmine,我开始尝试在服务端使用jsmine,到解决了与ide集成、Promise测试之后,我们还需要用不同的方式来做单元测试吗?

 

四、异步流程控制:Promise,Q.js

茴香豆的茴,有N种写法。所以,专家告诉我们,处理异步流程,除了回调函数方式外,还有事件方式、订阅发布模式、Promise。我的答案只有一 个,Promise,in Q.js。 在我们第一个项目中,我们避免使用太多第三方库,所有异步流程的处理,均老老实实的用嵌套得晕死的回调函数处理。这个,虽然折磨了大家,但很 明显是每个人可以快速的理解、快速做到的。不过,第一个项目中,遇到有十几个步骤的复杂计算的时候,层层嵌套几乎令我们团队出现一位精神失常者…为了 避免家长打上门来,老将出马…我用了一个通宵,在async.js(一个几乎居垄断地位的异步流程库)、Q.js以及其他一些方式中徜徉。

很惭愧的说,Promise的理解看似轻松,但在两个小时的时间里,我发觉自己很难真正的理解,这是很少见的事情,我照着镜子,看着那一向自以为性能不错的人类脑袋,沮丧的叹息。在项目进度的压力下,我选择了async.js…

之后的空闲时间,我终于经过两次波折,彻底的理解Promise的概念、使用的细节。在第二个项目开始之前,我用2天的时间在团队传播,并订下了非常不近 人情的编程规范:本项目不允许出现回调函数方式、不允许使用async、只准使用Q.js Promise。所有不符合此规范的代码将被退回,所有于此有关的问题我会随时解答。

原因是什么?如果没有Promise,node.js的编程将是一个异常枯燥、乏味、不可靠、江湖风格的苦差。我上升到这个高度,估计会面对有一千个番茄 加两千个鸡蛋,但,信者得永生。扁平的流程处理,统一的编程模式,链式的编程风格,无与伦比的异常处理。async.js实现的异步流程,所有的代码是相 关的。Promise则可以做到各步骤全不相关,嗯,想到了最基本的”封装”了吧?这就是所有的理由,之所以选择Q,也是降低学习的难度—我们在 angular.,js前端,已经模糊的使用微缩版的q.js了。

五、前端框架:Angular.js

前端框架,近年如同地下世界的老鼠,数量十分庞大。

Angular.js、微软的Knockout、某人推崇为第一的ember.js….等等等等。

我测试过多种之后,选择angular.js,这是入门简易,但学习曲线陡峭的框架。理由:我比较后,发现angular.js的代码量比多数的框架,精 简许多,在理想和现实中折中得相当平衡。结合REST,我们几乎可以方便的制作全静态的应用,当然,每个地方都是无刷新的。

 

没有草稿,随手而写,好象也没有什么修改。其他的几个选择,相对而言更好理解一些,不罗嗦。使用mongodb或许是一个错误…不支持事务,是个很要 命的问题。但也坚持很久了…我们的团队,始终是不能回避noSQL的,而noSQL的第一选择,目前仍然是mongodb,至少从思维方面,大家目前 已经非常熟悉和习惯。node.js真正的在企业中作为主力方向,国内估计并不太多,很多资料匮乏。我建了119874409群,欢迎诸位同好交流。

node.js的年龄,已经十岁,似乎并不容易成为真正的主流之一,但我本人,仍然很看好今后的发展,考虑到其轻松跨平台、独特的异步模式、与C++天然的亲和,甚至在桌面开发、安卓平台上的一些尝试,node.js极可能成为重要的技术方向之一。

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏