
44
|
第
4
章
多时间,并减少心智负担。当代码限定在一定的范围内时,总是比分散在应用的多个部分
时更容易让人理解。
当库甚至逻辑被用于多个业务领域中时,比如在表单验证库中,你有以下几个选择。
复制代码
代码重复并不一定总是一个坏做法,这取决于优化代码的目的是什么以及重复代码的整
体影响。比方说,有一个组件根据用户状态和它所在的视图的不同会有不同的状态,且
与其他任何领域相比,这个组件在某个业务领域中经常发生变更。你可能想把这类组件
集中起来管理,但请记住,每当有一个集中管理的库或组件时,必须建立一个可靠的管
理机制,以确保当这个共享的库或组件发生更新时,它也会在每个使用这个共享库或组
件的微前端中被更新。当这种情况发生时,还必须确保新版本不会破坏任何一个微前端
的任何功能,你需要协调多个团队一起升级。这样的话,这个组件并不难实现,而且对
于每个使用它的团队来说,它都将变得更容易构建,因为需要考虑的状态更少。这使
得每个团队都能以自己的速度独立开发,提高了交付速度并且降低了每个团队的外部依
赖。当需要复制的代码不是很多时,这种方法效果最好。而当有几十个类似的组件需要
复制时,这种方法就不再适用了,需要做的是把它们抽离成一个库。
将代码抽离到一个共享库中
在某些情况下,你确实想将业务逻辑集中到某个库或者组件中,以确保每个微前端都使
用相同的实现,比如集成支付能力。因为结账用的表单中实现了多种支付方式,包括表
单验证逻辑、错误处理逻辑等,所以复制如此复杂且精妙的东西是不明智的。而创建一
个共享库有助于保持跨应用的一致性,且可以简化整个平台的整合过程。在自动化流水 ...