大型项目之一云多端

以下纯属个人意淫：

随着各种小程序的出现,前端开发面临一个问题,就是同一个项目需要在不同的小程序展示,甚至还有h5版 pc web版,如果真对不同的端编写同样一套代码,显然是多余的，这有点像app的发展过程,自从ios和安卓出现之后,人们就从来没有放弃过使用一种语言同时开发ios端和安卓端的尝试,从phonegap到hybird再到rn,最终来到如今的flutter,

而真对小程序的多端开发思路也是一样的，希望用一套代码来生成对应平台的代码,最终完成生产率的转化，这应该也是最终的方案,然而本文所讨论的并不是这种方案,本文所讨论的是关于在不知道有多少端的情况下 如何最大化的复用代码,这本质上和flutter的愿景有点类似,flutter希望真正的统一客户端界面开发,他希望无论什么样的终端，都可以使用flutter来开发,并可以达到媲美原声的效果。而我的方案则是将业务代码与视图代码分开,然后视图代码使用不同终端的语言去编写,同时调用业务代码来完成具体业务。

我无法否认flutter代表未来,但就目前而言,flutter不会给出跨任何小程序的解决方案。

以下是跨小程序的解决方案：

 

1：代码分离，最重要的是将业务代码与应用逻辑代码分离,分离的原则是最大程度将可以复用的地方抽离出来,

　　1：我们通常会把业务逻辑写在model层,所以首先肯定要把model层抽离出来

　　2：所有有关于数据的处理全部抽离出来,这是对第一步的补充,理论上我们的程序应该是所有的数据都走model来取,同时model层会从不同的地方来获取数据(api 本地缓存 内存缓存)

　　3：数据验证最好放在Model层,这样做的目的在于让view层真正做到只关心展示和监听用户操作,同时Model层会定义具体的格式来告诉view层 哪一个字段验证失败

2：model层构建方案

　　一旦将model层抽离出来,就需要确定model层的技术实现,是自己定义一套通信机制 还是采用现成 方案,既然是跨多端 最好自己实现一套,而目前通用的有mobx

3：model层管理

　　既然将model层抽离出来,必然设计到model层的引入 更新等,可以采用npm私有库的方式(虽然npm的建立初衷并不是此),因为使用npm可以很灵活的让项目集成进model,同时更新model层也很灵活

4：model层设计

　　一旦model层独立出来,model不在与具体的view交互，他所关心的只有业务逻辑,所以model必须提供一个配套的具体文档以供view开发者使用

 

如何开发你的view层:

view单独抽离出来之后,view层并不是不关心业务逻辑了,很显然你需要关心你的业务逻辑 并在合适地方调用model的代码,那如何提高view层的开发效率呢,我们这里可以参考有赞的业务型组件思想,view层的开发需要两个人,一个人不需要关心业务逻辑,他只关心页面的开发,（这有点类似于很久以前.net开发的时候前端人员把开发好的页面直接丢给后端,）而另外一个人只关心项目架构和衔接model层,这样每一个都有自己的角色。另外后期专门开发业务型组件的人可以将组件放到私有库,(后期肯定会可以复用)

利用业务型组件来开发view,我们其实仅仅需要针对不同的终端开发不同的界面而已

 

这样做的目的是什么呢？看起来只是定义了一堆规则,将原本可以很简单完成的事情绕了一大圈才完成。

　　model层的抽离在于多端代码最大程度复用

　　view层的划分在于业务型组件的后期复用,这也符合关注点分离原则,不同的人关注不同的事情,有的人只需要关心界面实现和兼容性以及动画处理,而另外一个人只需要负责关心项目架构和model层对接

这样的划分是否利于项目后期的可维护性？

　　我们想想如果不去这样做的话,会是什么情况,我们可以使用taro实现一套代码多端运行,然而从phonegap到RN,这种方式真的很好的解决了我们的问题了吗,phonegap面临的是体验性不如原声,而RN一直没有解决关键组件性能问题，如果涉及到比较精细化 要求比较高的场景RN的性能问题就会暴露无疑,这也是为什么会出现flutter的原因,如果我们分别对每一个小程序单独写一套代码,(我承认这是可行的),然而当涉及到比较大的新需求和逻辑改动,你需要陷入到多个小程序的汪洋大海中,

　　而是代码复用方案,当遇到新需求和改动的时候,负责model层的人会专注于业务逻辑的改动,他不需要改动别的,而负责业务型组件的人 则只需要关注页面中修改的部分 他也不需要关注业务逻辑改动的部分,而负责衔接model的那个人因为省去了修改视图和业务代码的工作,所以他只需要关心衔接部分就可以了,这种方案只适合于大型项目,如果用在小型项目绝对会得不偿失,

 

最终的方案：

一个单独维护的model层

针对不同终端设计到项目框架

业务型组件私有库

 

1：然后将业务型组件从一个界面中剥离出来肯定是一个仁者见仁 智者见智的问题,不同的角度都会得到不一样的结果,然后在这个问题上不应该交由技术人员去决定,而是交由产品人员去决定,既然是业务型组件,必然是业务的封装,无疑 产品人员在这个地方比技术人员有更高的话语权

2：在封装业务型组件的过程中,又会存在一个封装度的问题,是尽量将配置外放 还是尽量将配置写在组件内部,配置外放的好处是更加定制化,但是繁琐的配置无意增加了使用人员的复杂度，将业务逻辑封装在外部,只暴露出少许的必须可变的参数，所以应该尽量避免复杂的配置,毕竟业务型组件与通用型组件的使用场景不同。

 

最终的view界面编写会有两个形态：

    1：只根据少许的配置文件即可快速得到一个定制化好的界面,字体 颜色 风格 行为 任何东西我们都不需要去关心

     2：一个类似.net webform的可拖拽的快速界面生成工具