简介：大前端团队如何选型技术？如何快速上手？如何高效协同？让我们看看快成科
导言
从 2017 年开始，GMTC“移动技术大会”就更名为“大前端技术大会”。发展至今，混合开发、原生开发、前端开发等概念正在深度融合，组成“大前端”团队。
大前端团队如何选型技术？如何快速上手？如何高效协同？让我们看看快成科技如何解决这一问题。
缘起两地三团队
快成科技是网络货运领域的领军科技企业，领域排名市场前三，平台有 3w+ 大宗商品货主，将货单发布到平台，由 60w+ 的卡车司机接单承运，每年产生 120亿 的运费交易额。
以司机端为例，需要承载从发单抢单到从进出场管理，从在途路径监控到金融白条加油加气等一系列相互强关联、流程链条长的业务。这些任务由两地三个研发团队，共同分工协作完成。
在 7*24 小时不间断的客户服务和每月 2-3 次发版的高度迭代中，技术框架瓶颈逐渐凸显，具体包括：
• 在系统框架方面，初始框架是原生 App+HTML5，传统 web 存在启动白屏和性能响应不流畅，大大降低了用户体验；
• 在发版周期方面，研发部门多，产品链条长，部分企业需要更多的个性定制化服务导致发版期待周期不一致，频繁的发包更新不仅降低了运营效率，也给客户带来了频繁更新的困扰；
• 在体验一致性方面，原生开发依赖系统框架，因为原生特性不同，而导致各厂商多渠道平台中差异化凸显，多平台性能、体验差别较大；
• 在多部门协作方面，常用开发语言、前端 JavaScript 框架等不尽相同，不能及时根据需求张弛和上线 DDL 来灵活调配技术人员协作开发。
在快成科技业务持续高速发展的背景下，优秀的技术架构是“提质增效”的保障，系统重构势在必行。快成的小伙伴们开始寻觅优秀的架构，解决场景问题。
选型四维度
快成小伙伴针对发现的问题，讨论出四个选型维度：
• 框架成熟度：简单来说，就是这个新技术是否靠谱，百亿的业务压力，没有太多的试错空间；
• 迁移成本：如果想得到新技术带来的收益，需要我们付出什么代价，例如新技术的学习成本、原来架构的改造成本等；
• 社区氛围：主要是看跟进这个技术的人够不够多、文档资料是否丰富、遇到问题能否得到帮助等；
• 考量基础上兼顾性能、跨平台和动态性。
定好技术选型考量目标之后，团队对常见的跨平台方案诸如 React Native、Weex、Flutter 和小程序进行了一系列的调研以及 Demo 制作，横向比较如下：
正在进入技术选型困境的时候，快成物流科技偶然接触到了源自支付宝技术框架的mPaaS，通过使用 mPaaS 小程序容器，整合 mPaaS 框架、离线包和复用 h5 插件，依托于性能强劲的 web 渲染引擎，完美符合了我们对技术选型的期望与要求。
动手试试看
选定技术选型之后，在重构初期，针对项目工程建立以及划分上，我们同事之间进行了一场激烈的头脑风暴，最终选定了在多部门协作前提下进行轻量组件化并行开发多个小程序并进行动态下发的方案。
快成团队从协同、技术等多角度，进行框架的逐步导入。
标签：加持,框架,程序,技术,mPaaS,选型,快成,提质
来源： https://www.cnblogs.com/ipython258/p/14804761.html
本站声明：
1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。