标签：维护   ppt   ios   核心   ref   后端开发   根据   word   tom   

一、大前端

　　简单来说，大前端就是所有前端的统称，比如Android、iOS、web、Watch等，最接近用户的那一层也就是UI层，然后将其统一起来，就是大前端。大前端最大的特点在于一次开发，同时适用于所有平台，开发者不用为一个APP需要做Android和iOS两种模式而担心。大前端是web统一的时代，利用web不仅能开发出网站，更可以开发手机端web应用和移动端应用程序。

　　由于node的出现，前端工程师不需要依赖于后端程序而直接运行，从而前后端分离起来。所以当开发一个新产品的时候服务只需要写一次，但是面向用户的产品可能有很多，例如网站、Android客户端、iOS客户端和微信小程序等。由于各个平台使用的技术栈都不一样，代码无法复用，非常浪费人力、物力。那么有没有什么技术能够解决这一痛点呢？大前端应运而生，其实大前端的主要核心就是跨平台技术，有了跨平台技术，各个平台的差异性就抹平了，开发者只需要一套技术栈就可以开发出适用于多个平台的客户端。

　　目前的主流跨平台方案：Cordova/phoneGap、React Native、Weex、微信小程序、PWA和Flutter等，根据其原理性，可以分为四大类。

• H5+原生（Cordova、Ionic、微信小程序）
• JavaScript开发+原生渲染 （React Native、Weex、快应用）
• 自绘UI+原生(Flutter)
• 增强版Web App(PWA)

　　大前端不仅会成为移动开发与Web前端的发展趋势，也将会是未来的显示设备终端的开发技术趋势。大前端将做更多的终端开发、工程化等工作，而不仅仅只是开发Web页面。大前端工程师将能搞定所有端上的开发。与充满争议的全栈工程师相比，它更具可操作性。但同时对开发者而言，要会更多的技术栈，比如原生开发者要学习html、css、js等前端知识，前端开发人员也要学习Android或iOS的原生开发技术，然后了解一下常见的跨平台技术，只有这样才能更好的融入到大前端的这个大家庭中。

二、前后端分离

　　前后端分离是指前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互，例如通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦。

　　以前的Java Web项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司需要专业人才，小公司需要全才，但是针对技术而言，前后端需要分离。

　　大家一致认同的前后端分离的例子就是SPA(Single-page application)，所有用到的展现数据都是后端通过异步接口(AJAX/JSONP)的方式提供的，前端只管展现。详细点此处

三、敏捷模型

　　使用前后端分离符合敏捷开发模式，利用nodeJS层夹在前后端中间充当Controller，作为前后端之间的桥梁，增加灵活性。　　

　　从技术角度，使得项目从面向UI转变为面向服务，适合于超大项目的同一套后端，多套前端的模式，后端只提供数据Model，viewModel由不同的端自行渲染，即后端只要提供满足的数据需求就可以了，剩下的事情，就让“大前端”内部自己解决。

　　从开发人员角度，使得前后端可同时并行开发，前后端完全解耦。产品经理提出PRD（Product Requirements Document产品需求文档）、UI设计稿后直接前端开发（后端数据mock模拟），完成后直接递交客户预览进行可行性分析，通过后交由DBA（或架构师）进行数据库设计、后端研发人员（或架构师）进行后端设计等，中国人喜欢先设计数据库，外国人恰恰相反，甚至使用hibernate自动完成数据库的建表操作。前端先行往往使产品开发效率更高，且做到了敏捷开发中的测试先行（Mock数据最早做出），简单讲，就是将通常的“后端功能推动型”改为“大前端产品拉动型”，前端逆袭了，BFF(Backend for Frontends，为前端而存在的后端。

　　模式是测试专职维护BFF上的Mock数据，将设计的用例转化为实际可用的Mock数据，开发测试用同一套标准，减少流程和沟通上的损耗。

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

　　以前，想开发一个功能，首先考虑的是后端逻辑是怎么样的。很多时候，要根据后端现有的逻辑，修改页面的展示，交互的顺序等等。是一种“后端功能推动的模式”。现在，产品和“大前端”一起，领先后端至少一个迭代以上。遇到需求变更强烈的点，或者争论较大的点，可以考虑让内部版本运行时间长一点，比如领先两三个版本。等产品想清楚了，基本稳定了，后端再上。这样，产品思考问题的重点，就从后端现有的功能转移到客户现实需求上来。“需求拉动型开发模式”，解放了产品的思维，更容易设计出符合客户期望的产品。原来的模式是由后端推着前端走，现在的模式是产品和前端拉着后端走，思维模式是完全不一样的。“大前端需求拉动型开发模式”：先有个可用的产品，搞清楚用户喜欢什么，再接上后端实现。“后端功能推动型开发模式”：先做需求分析，评估现有后端功能，然后想办法满足客户需求。

问题是：“客户或者用户知道自己想要什么吗？需求分析能有效吗？”。相对来讲，如果有个可用的东西，真正用起来了，用户更加容易知道自己想要什么。比如“这个颜色最好改一下”，“这里的按钮碍眼，最好去掉”，“这里我想看更多的信息，最好能加上”。

 

前后端分离敏捷开发模式图：

大前端与前后端分离

标签：维护   ppt   ios   核心   ref   后端开发   根据   word   tom   

原文地址：https://www.cnblogs.com/guanghe/p/12205122.html