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

2周开发：按照敏捷的模式进行开发，将业务落地。“每日站会”要坚持开，及时沟通。开发每完成一项，测试就可以直接验证，注重效率。Mock数据由测试统一负责，开发测试用同一套数据，减少误会。这期的结束标志是2周之后的“评审会议” ，开发测试向产品演示完成的业务场景。

1周重构：这周对应的是敏捷开发里面的“回顾会议” ，也是产品、测试、开发进行充分沟通的一周。产品在公司内部试运行一周，进行验收，收集反馈，为下一期的产品设计提供数据支持。开发一方面可以修改bug ，更重要的是根据“回顾会议”的内容，进行流程改进，对“技术债”及时进行重构。也可以进行组件开发，提高今后代码的复用度。

特殊之处Mock数据

以前的Mock数据由开发自己负责，要么直接代码写死，要么借助Charles等工具。现在，将Mock数据由测试统一负责，直接生成在BFF层。
以前开发要写自测代码，单元测试代码；测试设计出用例数据之后，一般通过流程工具，比如JIRA ，要求开发自测。现在的模式是测试专职维护BFF上的Mock数据，将设计的用例转化为实际可用的Mock数据，开发测试用同一套标准，减少流程和沟通上的损耗。

内部版本

“大前端”开发测试完成的内部版本是半成品，是缺乏后台实际支撑的。内部发版之后，在内部的测试服务器上试运行。（开发版本运行在开发服务器上）。运行需要的数据由测试负责Mock 。
这个内部版本不能交给实际的用户使用，但是内部的产品，开发，测试可以使用，用来体验，查找bug等等。
对于后端开发来说，也很便利，服务开发好之后，有现成的产品用来测试，能省很多事。
向老板汇报，或者向客户展示，也很方便，有实际可用的产品可以体验，虽然数据是Mock的。这个跟看word文档， ppt ，原型设计，或者UI图，感觉是完全两样的。
修改成本小，一般来说， 70%的工作在后台开发， 30%的工作在“大前端”页面。在内部试用的那一周中，发现的问题，或者需求变更，可以非常容易的在下一个版本迭代完成。这个时候，后台服务的开发还没开始，或者刚刚开始，变更成本很小。

需求拉动