前端技术的选择

对于一些使用老旧技术架构开发的前后端未分离的项目我们就先不深入讨论了。因为那些技术已经无法适应和解决当前用户需求不管更新变动与软件开发高质量高效率之间的矛盾问题了。所以对使用这些老旧技术的项目，我们能做的策略应该是逐步地放弃他们。如果是维护方面的需求，可以继续修改BUG类的问题。如果要添加新的功能的话，建议不要在现有的项目上面做了。

如果继续在老旧项目上添加功能的话，不仅会使得原先的工作越来越难以维护，对于新的功能代码也会如泥牛入海，难以为继。

所以我建议对于新的功能，可以单独再写一个Service，如果同时需要UI和后端数据，可以做成两个前后端的Service，如果代码量可控的话，也可以放在一个Port上，但是一定要前后端分离。

这样子，在老的工程页面上添加一个新的入口引导到你的新服务上就可以了。

接下来就重点讨论在前端的技术选型。

先说一下Angular。

我个人非常喜欢这个架构，为什么呢？ 我以前用过AngularJS，那个技术确实非常麻烦，涉及的东西比较多， 导致程序员不得不关注一些程序以外的配置。 但是从Angular2之后，到现在的Angular9， 都是非常简单的，技术上也都是一脉相承的。这说明这门技术已经非常成熟，我感觉这是前端开发框架中的首选项。 可以毫不夸张地说， 你在Angular 2开发的组件，可以很轻松的转到Angular9上面， 没有太多难度。

即使你有AngularJS的老项目， 想转到Angular上，难度也不大。 我来说一下，为什么难度不大，有这么几部分你可以几乎百分百的重用的：

首先是CSS这一部分，几乎是完全可重用的。

其次是HTML这一部分，几乎是95%以上可重用的。

即使是Javascript这一部分，因为在Angular中普遍使用Typescript, 这部分代码需要重写。即使重写难度也不大，因为逻辑部分是可以100%重用的，Typescript又是Javascript的超集。

Angular的代码量要比AngularJS小很多，因为它更加干净，开发起来更舒服，性能上也更好。尤其是Angular 9以后，用上了IVY引擎技术，使得整体的工程加载性能提升了大约30%。这个改进对于前端程序来说是至关重要的， 这是因为前端程序的加载时间是用户体验的重要一环。

接下来说一下Angular中的数据处理方式。

Angular支持双向数据绑定，所以对于开发Self-Contained组件来说非常方便。变量修改可以引起界面的变化，同样在界面上修改数据也可以影响到变量，这就是双向的数据绑定。ngModel就是用来实现这个目的的。

如果要跟外部的组件进行数据的交互，在Angular中有这么几种方式：Input/Output，ngrx和Service。

Input负责数据的输入，你可以通过onChanges检测到数据的变化，通过Ouput返回数据的改变到上层组件。

Ngrx是Redux模式在Angular中的实现。这种模式增加了如下的组件来管理数据：

Action用来定义数据改变的动作类型, 每个业务类型都要定义对应的多个Action;

Reducer用来改变数据，一般来说，对应每个Action都要定义Reducer函数进行响应;

Effect用来进行HTTP请求向服务器要数据， 取到数据以后进行计算，数据准备好以后再次发送Action，通过Reducer来改变数据；

Selector用来监测数据的变化。可以通过subscribe一个Observable来监听数据的变化，也可以在模板中使用异步的pipe。到这一步，UI的数据才会收到更新。

所以我们可以看到，Ngrx增加了很多额外的技术点。这也就无形中增加了你所在项目的工作量。如果你的团队有很多人的话，需要兄弟们有饭吃，使用Ngrx来达到这个目的。

经常有同行跟我自豪的宣称他的团队多少多少人，他们感觉手下人越多，体现了自己的能力越大，这个地方实际上是值得探讨的。我个人不太喜欢一个团队太庞大，团队越大，沟通成本越高，工作效率越低。产出和产量都不会太高。

打个比方说，如果你团队有一百人，你可以直接领导和服务的应该在十人以内，那么具体来说就是你应该至少有十个子团队在作战。这些个子团队中可能又会有很小的团队。

当然，团队划分的考虑因素有很多，诸如磨合时间长短，工作习惯的相互适应，但是总的来说，团队的划分要根据工作效率的最优化来划分。

使用Ngrx的好处就是可以把战线拉长，让更多的工程师有活干。这样团队里面的每个人都会很忙，每个人都会有饭吃。这就是Ngrx的一个现实特点，因为它无形中增加了很多的层级和沟通环节。

所以，单从工作机会的角度考虑的话，可以使用Ngrx模式。一句话就是让有些兄弟们有饭吃。

接下来会讲Redux模式在React和Vue中的应用，效果也是一样的。

继续讲Angular的数据流动话题，上面已经提到了两种模式: 

Input/Ouput，通过层层传递方式实现数据的下行和回传；

Ngrx，拉长战线，实现单向数据流动；

另外一个方式就是使用Service。

Service可以通过DI（依赖注入）方式定义Service对象，有了这个对象之后可以通过对应的Setter和Getter对数据进行修改和读取，非常简单方便。对于不同的业务对象可以定义不同的Service，比如User Service，Product Service等等。在Service可以做很多事情，比如向服务器索取数据，也可以做一些缓冲数据的处理，Getter可以直接返回缓冲数据，数据从服务器返回以后，修改本地缓冲数据，通过一个Subject通知对应数据的修改。

用以上Service方式处理数据以后可以使得代码复杂度大幅降低，我个人非常喜欢。用了这种方式之后，可以毫不夸张地说，可以让你的团队的人员减半甚至更多，打个比方，使用Ngrx你需要6个工程师来做开发和维护，使用Service模式以后，你只需要一到两个人就够了。甚至，这一到两个人还可以管理更多的项目。这就是一很大的区别。

接下来我们说一下React。

最早它是以Library模式出现的，当然现在它也能够作为Library使用，同时也可以作为框架使用。这门技术的一个最大问题，就是没有一个标准，对于同样的一个任务功能，一百个React程序员可以写出一百种以上的实现。而且你很难说哪种好，哪种不好。因为彼此之间都会争论不休，这就是React社区的现状。程序库不统一是造成这种局面的根本原因，所以在React工程项目中，每次版本的升级都是一次噩梦般的经历。

接下来，说一个它的好处。它的一个好处就是上手快，尤其是对于没有任何网页程序开发经验的程序员来说尤其如此。因为它是把HTML当作代码写到逻辑当中的，也就是React独特JSX文件。这种模式是React的一个重要卖点。很多程序员痛恨React是因为这一点，很多程序员喜欢React也是因为这一点。

这个地方我们要提一下事物的两面性，上手快，并不见得是个好事情。因为程序库的选择是个技术活，对于新入行的程序员来说是个很大的挑战，这个挑战往往短期内看不出来，随着各种程序库版本的增加，发现越来越多的版本兼容性问题。有时候不得不放弃已经使用了很久的程序库。

React技术的发展是比较曲折的。从最开始的functional 组件模式到后来长达数年的Class组件模式，在使用Class组件模式的过程中，React社区发现代码的体积越来越大，程序的重用性越来越差，终于意识到为什么Javascript并不是面向对象的编程语言，而是基于对象的编程语言，于是为了增加代码的重用性，可维护性，同时减少项目代码的体积和复杂度，所以到目前强力推崇重回functional组件模式和Hooks。

每次的变动对于React程序员来说都是翻天覆地的变化。这些程序员不得不重新开始学习React技术，因为以前的技术不再灵光了。对于数据的流向管理，从React业内推崇Redux乃至影响到其他前端社区使用Redux，到逐步放弃Redux模式。这都是实践中得出的经验和教训。

这里也吐槽一下以程序库的模式调用React和Vue。这种模式依然还有人在用，实际上还是沿袭了JQuery这种曾经的前端王者也是目前的前端末路者的使用模式。直白的讲就是打补丁。

既然在老的技术框架项目上添加新的功能不是一个可取的办法, 那么这种程序库嵌入使用React和Vue的方式就是鸡肋般的存在了。因为那样做，只会使得现有的程序更加复杂，更加难以维护。

这里说一下Hooks的概念，这是一种在functional组件中使用的技术，旨在尽量多的重用共性代码，从而降低程序的复杂度。它依然遵循了单项数据流的规则，提供了Getter和Setter两个部分分别负责读取和更新数据。比如userName这个数据，如果使用Hooks你需要定义一个Setter如setUserName用来修改userName这个数据，如果想在其他组件中读取和修改这个数据，你需要在父组件中定义这个Hooks。然后在子组件中传入Getter和Setter。

使用了Hooks以后，React程序员可以完全摆脱Redux模式的限制，不再需要额外的定义类似Actions，Reducers，Effects，Selectors，大大的提高了工作效率，同时也减少了代码量和程序复杂度。

最后说一下Vue。

Vue的格局比较宽广。

在Vue中既可以使用Flux的双向数据流模式，也可以使用Redux的单向数据流模式。

它既试图吸收Angular的用户，同时也想吸引React的用户。所以在使用Vue的过程中，Angular程序员可以发现很多Angular技术的影子，比如双向数据绑定，模板中的逻辑判断，模板和逻辑代码的分离等等。另一方面，React程序员也发现了React技术的影子，比如模板和逻辑代码放在一个文件里面，可以通过Redux模式来管理单向数据流向。

到这里，我们大体了解了一下目前流行的三大技术框架，最后还是要归结到华为的可信软件开发变革的初衷，不管选用哪种技术，我们的目标是写出干净的代码，简单的代码，用最少的代码实现业务逻辑功能的最大化。