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极可能成为重要的技术方向之一。
Node.js之绝对选择的更多相关文章
- Node.js之绝对选择(2018版)
[这篇是很早期的文字,由于引用较广泛,担心误导,故按照现在的情形做一些修改] 几年前,完全放弃Asp.net,彻底脱离微软方向.Web开发,在公司团队中,一概使用Node.js.Mongodb.Git ...
- NVM、NPM、Node.js的安装选择
在安装和使用这三种工具时,我们有很多方式可以选择,这些方法各有优劣,每个人都有自己用起来比较习惯的配置,所以我在这里记录下自己比较习惯的一种安装方式与其他一些可能的选项. NVM.NPM.Node.j ...
- node js 安装时选择勾上path
勾上path则会自动配置环境变量,否则必须手动去添加nodejs的环境变量.
- Node.js 和 Python之间如何进行选择?
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 原文出处:https://dzone.com/articles/nodejs-vs-python-which ...
- Ubuntu 14.04下搭建Node.js的开发环境
最近想找一个轻量级且支持快速开发的服务开发平台,选来选去选择了Node.js,当时有几种选择: Python + Django(用过Django,虽然开发快速,但是感觉性能并不太好). Ruby + ...
- 微信公众号开发总结(Node.js + express + winston)
关于订阅号.服务号.企业号 官方定位 订阅号:主要偏于为用户传达资讯(类似报纸杂志),认证后每天可以群发一条消息,可达到宣传效果,构建与读者之间更好的沟通和管理模式. 服务号:主要偏于服务交互(类似银 ...
- 一名全栈工程师Node.js之路-转
Node.js 全球现状 虽然 Node.js 在国内没有盛行,但据 StackOverflow 2016 年开发者调查,其中 node.js .全栈.JavaScript 相关的技术在多个领域(包括 ...
- 深入浅出Node.js(上)
(一):什么是Node.js Node.js从2009年诞生至今,已经发展了两年有余,其成长的速度有目共睹.从在github的访问量超过Rails,到去年底Node.jsS创始人Ryan Dalh加盟 ...
- node.js内存泄露问题记录
先说一下.事情的来龙去脉. 公司开发一款游戏棋牌游戏,服务端的开发是IO密集型,开发的时候,考虑过使用python,java,node.js. 终于选择了node.js(node.js宣传的杀手功能. ...
随机推荐
- Asp.net中HttpRequest.Params与Reques.Item之异同
今天才注意到HttpRequest.Params与HttpRequest.Item这两个玩意竟然有微妙的不同.上午的时候同事被坑了发现这玩意的说明还真微妙. 场景再现: 前台提交一个POST请求到后台 ...
- 检测网页地址有效性java代码
package com.inspur.linkcheck; import java.io.IOException; import java.net.HttpURLConnection; import ...
- 《Linux内核设计与实现》读书笔记(十六)- 页高速缓存和页回写
好久没有更新了... 主要内容: 缓存简介 页高速缓存 页回写 1. 缓存简介 在编程中,缓存是很常见也很有效的一种提高程序性能的机制. linux内核也不例外,为了提高I/O性能,也引入了缓存机制, ...
- JBoss无规律自动关闭故障定位
转载地址:http://blog.knowsky.com/264489.htm 最近遇到了几次JBoss无规律自动关闭的奇怪现象,通过history历史命令和last登录信息,都看不到有人操作过的迹象 ...
- PDB调试Python程序
pdb是python内置的调试工具, 它可以在终端中调试Python程序, 这允许pdb在很多无法安装IDE的服务器上使用. 虽然远程调试使用广泛, 但在必要的时候(比如难以在本地搭建运行环境)pdb ...
- [自娱自乐] 4、超声波测距模块DIY笔记(四)——终结篇·基于C#上位机软件开发
前言 上一节我们已经基本上把超声波硬件的发射和接收模块全部做好了,接下来我们着手开发一个软硬结合的基于C#的平面定位软件! 目录 一.整体思路 二.效果提前展示 2-1.软件部分展示 2-2.硬件部分 ...
- jenkins2 Jenkinsfile
推荐使用Jenkinsfile代替将groovy脚本直接写在jenkins job里. 文章来自:http://www.ciandcd.com文中的代码来自可以从github下载: https://g ...
- JAVA软件开发职责
1.了解OO,AOP,SOA设计模式.J2EE的核心设计模式.应用架构模式和应用集成模式:2.熟练使用Spring.Hibernate/ibatis.Struts等通用性开源框架,并对其原理有深刻的理 ...
- Javascript入门学习
编程之道,程序员不仅仅要精通一门语言,而是要多学习几门. 本学习之源出自柠檬学院http://www.bjlemon.com/,特此声明. 第一课1:javascript的主要特点解释型:不需要编译, ...
- Leetcode 234 Palindrome Linked List 链表
判断链表是否是回文. 我直接将链表的一半进行倒置,然后将两半的链表进行比较 /** * Definition for singly-linked list. * struct ListNode { * ...