哎,接手公司的项目接的有点烦了,唠嗑两句,随便看看就行啦。
目前在公司负责一个组合项目,有点像个是大杂烩,把各种各样的功能从其它团队那里直接拿过来用。
做 SaaS 服务的公司,大概都会遇到这个问题吧。为了节省开发成本,就想直接从其它团队那里,把一个功能直接拿过来,稍稍兼容一下,然后直接上线。
这合理吗?这当然合理的不得了。
无容置疑,这是一个非常合理的想法,但是呢,在执行的过程中,没有统一的框架来协调每个模块之间的工作方式,这就像硬是要把两个脚的插头插到三个孔的插板上。
你说插不上去吧,使点劲也不是不能插上去。
吐槽吐的差不多了,怎么解决呢?
问题
要解决问题,首先肯定是找找问题是啥。复用 的想法肯定是好,那么问题是什么呢?
讲讲我遇到的问题吧。
我遇到的最主要的问题就是,对接的过程中没有统一的规范。每个项目拿过来之后,都需要单独出一套对接方案。我们还只是第一个接的,后面也许还会有第二个,第三个(如果能坚持下去话,但我觉得不太可能)。
想到后面对接的人还要经历一遍我们这样的痛苦,光是想想,我就想替他们流两滴眼泪。
怎么解决问题
上面提到了问题是没有规范。具体点是什么呢?是哪些对接的点需要规范呢?
在回答这个问题之前,先简单介绍一下我们的对接方式。
组合方式
我们多个产品,例如 A、B、C 三个产品,每个产品呢,都提供了 X、Y、Z 三个功能。之前的做法就是三个团队,维护三套代码,虽然功能相似,但是因为服务的平台不一样,所以还是有一点点的差别, 例如一个是服务于淘宝的,另外一个是服务于拼多多的。接口参数啥的肯定都是不一样的。
现在呢,我们要做一个 D 产品,这个产品呢,是服务于另外一个平台的,例如抖音。但是这个产品提供的功能呢,和 X、Y、Z 差不多。
所以,就有之前 复用 的想法了。想法没问题,但是做法呢,感觉有点蠢。
现在的做法,是以现成的产品 A 作为参考,提取其中的 X、Y、Z 功能,单独独立出来,给 D 这个新产品用。
哪些点需要规范
理想是丰满的,现实是骨感的。就上面的做法,我认为就有很大的问题,本来 A 平台就是特定的,以 A 平台为标准提取出来的组件,太具个性化了。如果不磨平个性化的菱角。势必是没办法复用的。
实现也证实了这一点。现在就回答一下上面的问题,我们需要哪些对接的困难点呢?
我们遇到的第一个问题,就是技术栈不统一。这个倒也是可以解决,qiankun 或者 iframe
都是可行方案。最终权衡下来,我们选择了 iframe
。
然后是第二个问题,授权,因为是 iframe,所以需要把授权信息传递进去。但是每个提取出来功能的授权方式不一样。 例如 X 功能的授权方式是通过后端跳转,然后把授权信息放在 cookie
里, Y 功能的授权却又是前端直接把 token
通过 query
的方式,传递到 iframe
过去。
然后是第三个问题,细节,因为 A 产品和 D 产品,不是服务于同一个平台,所以,在 D 产品中,需要修改一些特殊的细节点,例如某些文案以及某些表单选项等。
先记一记这三个问题,那么这些能通过规范来解决吗?
尝试设计一个方案
问题有了,怎么解决呢?
针对第一个问题,统一技术栈。理由到也是很充分,因为这并不是一个简单的功能,需要涉及到一些细节的修改,如果技术栈不统一,那么修改起来,成本维护就相对比较高。 对应的,针对开发规范,也需要对应的定制几套规范。
第二个问题,授权,这个通过规范,即可解决,规定一套授权方式,都按这个实现即可解决。
第三个问题,细节的修改,这个从产品的角度来讲,是肯定存在的,而且无法避免的。那么怎么解决呢? 这个问题也是目前遇到的最棘手的问题。
目前针对第三个问题,并没有太好的方案,能想到大概是组件颗粒度更细一点,通过细化组件,让这种修改影响的范围尽可能的减少。
其它问题
除了上述记录的三个问题,还有一些后端的问题。
目前有一个问题,就是数据不一致,D 平台和 A 平台的数据源提供的数据格式不一致。在我们接手 X、Y、Z 功能的同时,还需要处理一遍数据。真是心疼后端一秒钟。
针对这个问题,可以在设计的时候,设计一个标准的数据层,然后通过适配器模式,把 D 平台和 A 平台的数据适配成标准数据格式。
结语
大概就是这些吧,貌似也没有一个完整的方案。算了,懒得改标题了。针对遇到的第三个问题「功能的细节需要特殊化」这个问题上,应该还能有更好的方案。大概吧 😃