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

作为一家服务于全球不同类型客户的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的技术大爆炸时不再恐慌和迷茫。