Node.js之绝对选择

浏览数：30 / 时间：2015年06月09日

几年前，完全放弃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，我们几乎可以方便的制作全静态的应用，当然，每个地方都是无刷新的。