Node.js之绝对选择(2018版)

   【这篇是很早期的文字，因为引用较普遍，担忧误导，故按照如今的情形作一些修改】

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

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

    固然，最初并不是一切顺畅，每一个选择，每一方都是王婆婆，她的瓜绝对是举世无双滴。面对诸多王婆的时候，咱们也很可贵到客观的比较，选择每每须要本身来作。通过两个项目，才真正让一切顺畅起来。其中所涉的编程方式、各种细节甚至由此引起的不一样设计思惟，很明显经历了多处的反复。这个没有办法，node.js相对较新，大规模在一些公司应用的情形并很少，这类文字固然也稀少，咱们很难找到其余人概括的常规的团队开发模式。

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

    一、IDE：Webstorm，没有其余。

         visual studio code

    二、版本管理系统：Git，独一无二。

    三、单元测试：jsamine，先后端共用。

          jest

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

         react，最近五年的前端霸主

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

         单页面应用，不须要JADE之类

    六、socket.io+独立小模块：固然，这几乎是惟一可选的与客户端双向通讯的方式。但必定要注意，多数情形下，咱们只有不多的机会须要服务端推送，将这部份内容做为独立的小应用，是很是省事的作法。

    七、异步流程控制：Promise是惟一选择，并且从一开始就要强制使用，毫不可忽略，这关系到设计思惟的巨大差别，甚相当系到咱们是否真正可以在node.js方向坚持下来。咱们用Q.js，和前端Angular.js使用的微缩版Q.js保持一致，减小学习周期。

         es2016的async/await

    八、先后端共用代码：只要前端有可能用到的代码，必须以符合规范的方式，作到先后端共用。

 

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

    不是由于我性情不成熟，嗯，好歹我也算是超级资深的架构师、高级程序员、过程管理大半个专家...啊，还有没有其余的光环和帽子可戴？

    既然咱们在集中选择中左右碰撞后，得出告终论，咱们的选择就是惟一的...多数状况下，您看到这篇随手的文字，就再也不须要将这个痛苦的过程，重复一遍。我觉的这是真正的厚道...那么多客气干吗？噢，这可能有点"大家不用思考，元首都帮大家思考过了"的意思，这点很差...我在下面将几种主要选择的理由，列出来...以免从天而降的、聚合成团队的板砖。

1、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集成、单元测试框架的集成....

   嗯，一切以外的选择变成了浮云。

 

2、版本管理系统：Git

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

   可是，可是那个可是...这东西用起来比Tfs麻烦许多噢，咱们都不算是喜欢一个个敲命令的人吧？我本人率先使用，而后培训其余人，先行的过程虽然持续三天...可是：

   一、分布式确实是最人性的作法：再也不须要家中和公司服务器同步来同步去，不在同一城市也再也不是问题。

   二、分支成为主要的思惟...前提是合并、冲突惊人的简易。

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

    那么，你还须要考虑别的？

 

3、单元测试：Jasmine

    这个选择，纯粹是因为我天生的懒惰。 前端Angular.js，单元测试用karma...jasmine，我开始尝试在服务端使用jsmine，到解决了与ide集成、Promise测试以后，咱们还须要用不一样的方式来作单元测试吗？

 

4、异步流程控制：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了。

5、前端框架：Angular.js

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

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

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

 

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

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