前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >刘尚奇:JavaScript技术爆炸下的项目选型何去何从

刘尚奇:JavaScript技术爆炸下的项目选型何去何从

作者头像
ThoughtWorks
发布2018-04-20 11:11:39
9080
发布2018-04-20 11:11:39
举报
文章被收录于专栏:ThoughtWorks

作为一家服务于全球不同类型客户的IT专业服务公司,ThoughtWorks一直追求最卓越的技术,并用它们来解决客户实际的问题。而为了体现技术卓越,ThoughtWorks全球技术委员会(TAB)定期讨论技术战略,分析对行业产生重大影响的最新技术趋势,这便是我们看到的每年两度的《ThoughtWorks技术雷达》。 2016技术雷达峰会不仅能为您解读最新版《ThoughWorks技术雷达》四大主题之外,还希望能覆盖更多更具实践价值的专题,为您提供更多选择,也为各个优秀实践提供多一个展示和分享的平台。

《JavaScript技术爆炸下的项目选型何去何从》- 刘尚奇 今日分享!

《技术雷达之微服务架构》- 王健

《Cloud Enabled Stack Management》- 孙建康

《Docker打造App-Centric交付》- 钟健鑫

《技术雷达之构筑软件安全DNA 》- 韩锴

《海航集团的数字化转型》- 龙旭东,海航生态科技集团CTO

《企业内部开源及社交化编程:连接与聚合》- 林鼎军,某世界500强电信企业业务部产品SE

《Ruff,JavaScript 硬件开发新领地》- 郑晔,Ruff CTO

《实践演进式设计》- 袁英杰,ThoughtWorks首席咨询师

《传统企业的微服务架构转型》- 杨波,丝芙兰Sephora首席架构师

《通过CI/CD来保障数字化转型》- 刘宇峰,ThoughtWorks首席咨询师

大家好,今天的分享跟JavaScrip相关。过去几年JavaScript领域大爆发,各种新技术层出不穷。这里列出来的是曾经在技术雷达上出现过的JavaScrip技术,大家可以看一下上面的技术。在座的各位都是把握技术趋势的CTO、CIO,有这么多技术没听过会不会觉得很恐慌?其实不用恐慌,因为这些技术大部分都过时了。

有人曾经做了个统计,JavaScript领域每六周就会出现一个新框架。在这种技术爆发增长的背景下,每个前端Lead都会遇到这么两个问题:第一,我们面临这么多技术,如何进行正确的项目选型;第二,即使做出正确选型,一旦项目开始,我这个技术栈就已经绑定了,随着技术的更新,如何保证项目使用的技术不会过时。

今天我们就聊一下这两个问题。因为ThoughtWorks在全球有很多项目有很多技术,对这两个问题有我们自己的一些经验和实践,今天希望从选型,架构和升级这三个维度来分享一下我们的看法。

选型很痛苦,面对这么多技术选择,我们如何做出正确的选型?难道是根据开发者个人喜好?没错。但你不能只看某个开发者的个人喜好,而要通过整个行业整个社区里的开发者的喜好和倾向把握技术趋势。

接下来我们过一下在技术雷达上出现的JavaScript技术趋势。我们会从工具,类库,框架和语言这四层来浏览一下。首先是跟JavaScrip相关的工具,我们用很多地工具进行打包、构建等前端工程化的实践。我们还会使用一些类库,这里要把类库和框架区别开,使用类库是在调用类库提供的函数、API;框架的侵入性更强,它通过IoC控制反转接管了我们整个应用的生命周期。最底层是语言,在JavaScrip这个社区里还有语言有很多可以替换。

这是我们最新一期的技术雷达上的所有JavaScrip的技术,我们按照工具类库框架和语言这几个维度一个一个过。

首先说工具。在过去几年里JavaScrip工具大量爆发,很多工程化的实践已经引入到前端。比如构建工具,比如Scaffold工具,比如依赖管理工具,甚至是像RequreisJS这样的模块管理工具,因为JavaScrip之前在语言上缺少命名空间的特性。面对这么多工具如何进行选择?大家看到虽然有很多选择,但很多工具解决的问题是差不多的,只是API有细微的差别,比如grunt和gulp,比如RequireJS和CommonJS。无论选择哪个工具其实对实际项目没有太大的区别,都是没有问题的。

在技术雷达上曾经出现过的依赖管理工具有npm, bower, volo,但是最近我们发现越来越多人只使用npm进行管理。比如一个压缩混淆的工具UglifyJS,当发生更新的时候会优先更新到npm上,然后其他维护者才port到grunt, gulp插件里。这个时候用npm管理项目是足够的。这期雷达上另一个亮点是webpack,除了资源的加载优化,它还做了很多工作,它的很多loader也可以编译、打包、包括做ES6的转换,接管了很多grunt, gulp等构建工具的工作。现在使用npm script+webpack就足够完成常见的前端任务了,不用再引入其他的工具。

说到类库,过去一年最流行的类库是什么?ReactJS。这个表是Stackoverflow 2016 developer survey里技术趋势的胜出者,ReactJS以311.3%的增长速度位列首位。同样我们在雷达上看到跟ReactJS相关的技术大爆发。比如React Native可以进行跨平台的mobile设备开发,比如跟架构相关的Flux和Redux,比如跟React搭配使用的Immutable.js和GraphQL。很多人说React不是框架吗,其实React只是做了MVC中的V的部分。很多时候我们更愿意选择一个轻量级的类库而不是大而全的框架。React基于组件的模式,单向绑定和virtual dom等特性可以帮助我们更好的构建大型应用。在这个时间点React成为我们ThoughtWorks首选的前端技术。

说到框架不得不提到AngularjS,我所在的项目也是从2011年开始使用Angular,非常火的技术。但是在最新一期的技术雷达里,我们把它从雷达的实验象限移动到评估象限。在2016年5月这个时间点上,我们对Angularjs是持谨慎态度的。首先我们看到很多使用AngularjS的团队没有考虑到项目真实情况,在缺乏server renderring和SEO支持的情况下做面向互联网用户的SPA可能并不是那么友好。其次我们看到随着项目规模的增长,状态维护成为一个问题,数据双向绑定的方式会让复杂度增高。另外Angular 2跟Angular 1出现了很多api的break change,目前社区里没有太多成功迁移的案例,现在看AngularJS技术的未来充满了不确定性。

如果你一定要选择一款框架的话,技术雷达还有其他一些选项。比如跟AngularjS同期EmberJS,约定胜于配置的风格和好用的CLI工具等特性对开发者都是非常友好的。还有一个是Aurelia,它的作者曾经是Angular core team的成员之一,后来在Angular 2的路线上产生比较大的分歧,离开了那个core team创建了自己的框架。

接下来说一说语言,因为JavaScrip语言十天之内设计出来的非常仓促,很多特性缺乏考量。曾经JavaScrip作为一个脚本语言来处理表单验证之类简单的逻辑,现在我们要做富前端的应用,很多应对大规模工程化的语言特性是缺乏的。所以社区里也出现了很多编译到JavaScript的语言。我们技术雷达上曾经在2011年出现过CoffeeScript,2012年出现过ClojureScript,2014年出现过TypeScript。包括谷歌的Dart也是类似的定位。这些语言或者弥补了JavaScript的一些缺陷,或者提供了更多的特性来支持前端工程化开发。

然而回到Stackoverflow 2016 developer survey,这一次的图表是技术趋势的失败者。我们在这个技术趋势上可以看到第CoffeeScript和Dart分别在Losers的第三位和第四位。我们ThoughtWorks的项目也有一些选用CoffeeScript或ClojureScript,刚开始大家作选择时候非常兴奋,因为有很多非常fancy的特性,可以用自己喜欢的编程范式。然而随着时间发展,我们发现因为这些语言的社区没有JavaScript大,工具和类库没有JavaScript多,有的问题得不到帮助,新人进项目的时候也是需要一定学习的成本。所以从应用的角度我们可能并不那么推荐使用JavaScript的替代语言了。

而在去年发布的ES6里包括了很多期待已久的特性,像module, destructuring, promise, class,像string template和arrow function这样的语法糖,等等等等。确切地说去年发布这个标准叫ECMAScript 2015,TC39承诺以后每年会发布一个新的版本。现在如果开始一个新项目,我们建议直接采用ES6进行开发。

从语言到框架到类库到工具,从下往上变化速度越来越快。新工具涌现的速度可能按周或天来计算,但是能设计语言或写编译器的还是比较少,所以新语言的出现速度比较慢。但是对于项目来说,从上往下的依赖程度是不断加深的。工具和类库比较容易替换,但是框架对项目侵入性就比较强了,使用的语言更是难以改变。所在做技术选型时我们建议大家看一下这个维度。在框架和语言层面应该尽量谨慎,选择一些选对成熟适合的技术。而对于类库和工具来说可以放开一些,尝试一些新潮技术,享受技术红利带来的生产力提高。

接下来聊一下架构,评估一个架构的维度很多,今天说的是JavaScrip的技术爆炸,我们聊一下怎么样的架构能帮助你更好的升级技术。十年前很少有前端架构师的职位,因为大家都把JavaScript当做脚本嘛。如果是你告诉别人你是个前端架构师,大家都觉得你是做编译器或者做游戏的。

一个比较好的前端架构需要对项目进行一个合适的分层和抽象。我们做后端应用的时候会去注意,但是做前端应用的时候往往把代码堆在一起。我们应该尽量使用Plain Old JavaScript Object,当你的技术栈升级的时候这部分代码是不会影响的。第二是前端架构应该更加重视模块化,包括依赖注入。我们最早在global scope写代码,后来用IIFE去做作用域,现在我们的语言特性或工具的支持能够更好的帮我们做这样的事情。我们应该用这样的一种模块化的风格,把我们需要的依赖注入进来,方便我们的组件更容易升级。第三点是依赖反转,我们大部分时候使用框架时让我们的项目依赖于框架,你想要替换或升级一个框架是非常痛苦的。如果你看后端架构里的六边形架构,整洁架构,都是把依赖关系反转过来,让框架等基础设施依赖领域层。你应该在核心层里构建代码,然后把核心层注入到框架中,框架里的代码只是调用核心层的胶水代码,把这个依赖反转过来。最后好的架构应该是易于测试的,只有具备完备的测试,我们才有信心去做技术升级。

这一期雷达上跟架构相关的条目有这些:Flux是Facebook提出的一种架构范式,他们认为MVC做错了,至少不适合我们前端的应用。当然对于Flux的理解和实现有很多种,Redux是其中的一种。Redux实现了Flux,但是更多受益于Elm启发。它是一个真正的单向数据流,所有的状态存在于一个单一state tree,所有对状态的改变改变都要通过reducer走。如果你跟跟后端架构里的CQRS, Event Sourcing进行对比,你会发现这种思路是非常像的。状态管理正在成为大型前端应用的一个难题,你要要维护的状态,有可能来自一个用户的操作,有后台网络请求返回,有可能是浏览器缓存,管理起来非常复杂。很多用Angularjs的团队遇到这样的问题就迫不及待的转向React,其实大可不必,因为这个框架的迁移成本是非常高的。你可以通过引入Redux的方式来帮助项目降低数据管理和状态维护复杂度。雷达还推荐了一个小工具叫grasp。以前大家做重构更多是靠sed, awk这样的Unix命令行工具做文本替换,而grasp可以让我们在JavaScrip的AST层面进行选择和操作。

我们想要去传达的一个观点是,架构比技术选择更重要。与其花很多的时间纠结我应该用什么样的技术,不如花更多精力投入在架构设计上。

最后聊一下升级,是否要升级是一个迷思。不像电脑和手机点个按纽就升级了,在项目里升级一个技术成本非常高,你要花本来去开发feature的时间进行升级,你要冒着项目被破坏的风险。所以我们要认真考虑一下,是否要升级。我们建议大家为自己的项目建立一个适合自己的升级策略。

为什么要升级?有时候升级是必须的。比如AngularJS的dirty check机制导致超过2000个watcher时有严重的性能问题,而我们的项目里就有这么一个几千行的大table。Angular后面的版本的bind once特性可以缓解这个问题,我们就做了升级,这样的升级对我们是有意义和价值的。如果一次升级对我们的项目没有太大的价值,只是开发者的个人喜好,那这个升级是可以暂缓的。什么时候可以升级?不同的项目有不同的策略。有的项目时刻可以发布,技术栈可以跟着业务需求一起升级;有的是项目做不到这么好的持续交付,那对产品来说也分忙季和闲季,我可以在忙季交付业务功能,闲季进行技术升级。还有技术升级要兼顾业务价值,你需要投入时间人力去做这个升级,就意味着有同等工作量的业务价值不能交付。我们要根据自己的情况评估这个业务价值。还有评估风险和受益,我们都说如果软件没有坏不要改。但是升级恰恰相反没有坏也要升级。所以就像投资一样,当你要冒着一定的风险,你要想带来的受益有多少。还有一点是小步前进,我们看到太多案例,试图去做一个颠覆性的升级改变,最后却失败了。所以建议大家保持baby step,逐步的替换和升级自己的项目和技术。

回顾一下今天的内容。今天讲到技术选型,在工具、类库、框架、语言这个顺序越往核心选型应该越谨慎。第二是架构,合理的架构应该胜过技术选择。另外建议大家为项目建立适合自己的升级策略。以上是今天的内容,抛砖引玉希望能引发大家更多的思考。也希望大家在面对JavaScript的技术大爆炸时不再恐慌和迷茫。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-05-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 思特沃克 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器镜像服务
容器镜像服务(Tencent Container Registry,TCR)为您提供安全独享、高性能的容器镜像托管分发服务。您可同时在全球多个地域创建独享实例,以实现容器镜像的就近拉取,降低拉取时间,节约带宽成本。TCR 提供细颗粒度的权限管理及访问控制,保障您的数据安全。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档