大前端架构思考与选择( 二 ) _前端架构

整个开发流程太长，导致相互等待，造成浪费。针对这个问题，可以考虑在BFF层将开发流程分为两部分。“大前端”作为一个独立开发部门，领先后端一个版本发布周期。

具体做法是，对于新业务，将Mock数据生成在BFF层，对于各种端来说，相当于后端服务已经好了，可以直接进行联调，不需要等待。这样就把前端对后端的数据依赖去除了，更加灵活。
组织结构针对上面提到的“大前端”技术架构，需要相应的“大前端”组织结构相对应。
分类思路

“大前端”是针对整个后端来说的，所以这一层是按照职能来分的
在“大前端”下面，是否仍然按照职能来分呢？比如IOS开发， Android开发， H5开发等等。这种分法是可行的，然而收益不是很大。这只是将一个个小部门“组合成”一个相对大的部门，融合度不是很高。另外一种融合度更高的划分方法是在“大前端”下划分为“基础服务” ， “业务开发”两个子部门。

文章插图

“基础服务”的主要职责是为整个“大前端”部门提供公共服务，公共组件，周边设施等等。根据需要和实际情况可以分为“架构”、“工具”、“组件”等小组
“业务开发”的主要职责完成业务部门的需求。根据业务发展情况，按照具体业务划分小组

管理管理方式跟组织结构相适应，采用职能管理和敏捷管理相结合的方式。
职能管理
“大前端”是按照职能分的，跟后端相对应，是技术部下面的一个子部门，按照职能管理方式进行统一管理。
敏捷管理：

“大前端”内部，主要还是按照业务分组的，并且由于BFF的引入， “大前端”内部可以形成开发的闭环，可以考虑引入敏捷管理。
要实行敏捷管理，需要产品和测试的支持。根据业务，将相关的产品、设计、测试、开发（“大前端”）组成虚拟团队。

流程和管理模式相对应，采用瀑布模型和敏捷模型相结合的方式。
瀑布模型
职能型组织，采用瀑布模型的开发流程是合适的。产品部，技术部，测试部一般跟产品开发相关度比较大，按照瀑布模型联系起来。这里考虑前后端分离的开发模式， “大前端”可以独立完成开发闭环，虽然BFF层的数据是Mock的。
另外，大前端版本的开发要求领先后端一个版本以上，这样也方便对于后端服务的测试。简单讲，就是将通常的“后端功能推动型”改为“大前端产品拉动型”