接上篇：https://developer.aliyun.com/article/1225908?spm=a2c6h.13148508.setting.30.595d4f0eudDbz0
三、 未来研发模式构想及路径
1. 端侧组织职能的再分配
在行业的岗位职能中，客户端（iOS/Android）开发工程师、前端（Web）开发工程师，以及一些上层的细分岗位如Flutter工程师开发、RN开发工程师、小程序开发工程师等角色众多。而各类移动端中间件、移动端构建平台的相关研发工程师的岗位角色也需要相互配合，从这个角度上，岗位的细分一方面带来协同成本的显著增加，一方面在人才发展中造成不同的Job Code的天花板太低，不利于人才的长期成长。因此在新的研发模式的设计中，我尝试先定义更少的研发角色，岗位的融合一方面推进带来协同规模的显著下降，一方面推进交叉领域的组合创新，在历史上这种组合创新的例子比比皆是，我们的众多端侧容器技术的发展如RN/Flutter等，都离不开客户端和前端的深度融合。在效能工具上这种端侧全栈的岗位融合，相信也有机会创造新的生产力
以下我会重点介绍新研发模式设想中的两种核心岗位设计。
应用开发工程师【应用侧多岗位融合带来组织活力】
从敏捷组织为原点出发，我们来思考未来的研发角色的角色定义，从组织的角色来看理想中的极致应该是应用开发工程师可以既懂前端又懂后端，懂数据而又可以对常见算法进行应用，在公司的大背景下当然还有“用好云”的要求，从这个角度来看，业务在协同侧只需要与一个技术团队或一个技术人协同而不再需要与多岗位角色的团队进行协同，这当然是最理想的状态。当然这个对人才的能力以及配套的基础设施的能力要求都太高。
我们退一步从三年的视角来看，在端侧是否有机会做到岗位的融合渗透，我认为是有这样的机会的。我们设想这样的一个场景，以商品发布为例，一位同学负责商品的客户端链路的发布体验问题，同时由于发布还存在大量的长尾页面如发布引导，发布的一些常用的频道也由其负责。在这样的场景下，各场景的协同串联就不再需要多个岗位来协同，产品和UED只需要跟一位同学进行交流，大幅减少信息传递的衰减以及说服技术的成本。另外串联过程中会涉及到的一些联调工作，如发布频道引导到发布的场景，在单一岗位协同的情况下很多技术内部的联调的成本就会被干掉。
当然以上的描述中对人的要求可能是要做端侧的全栈工程师，即懂iOS/Android/Web开发。这里面最核心的挑战来源于学习成本。而实际上今天通过基础设施的升级是有机会大幅度减少端侧开发的学习成本的，同样以闲鱼团队目前已有的实践举例，在端侧80%的需求承接使用Flutter进行交付时，大量开发工程师的技术栈的底线要求变为熟练掌握Dart及Flutter相关知识，而在iOS和Android侧的要求变为了解和做较为初级的使用即可。这大幅降低了一人开发两端的技术要求。同样的，当前端可以使用JS/TS进行App的产品侧开发时，在产品链路能投入的研发基数就会大幅上升，这部分的前端的要求可能是熟练掌握React等相关的框架和前端语言，同时熟悉Flutter的相关知识即可。在未来的组织要求中，我认为我们在应用侧的人才应该是T型人才，在上层语言和框架上至少要对Dart&Flutter或TS&React要有较深入的理解，同时对客户端或前端的一些基础知识有一定的了解即可，这部分的能力不足可以通过基础设施的建设来补充，在后面的章节会提到。
基础设施开发工程师【基础设施侧各领域形成纵深打好基础】
由于上层应用开发工程师需要掌握多门应用开发语言或者框架，这注定代表了他在某一类的知识上不会特别深入，这个时候需要基础设施这一侧提供相应的能力，典型的有我们所说的端侧容器，比如Flutter/RN/Weex。另外包括发包流程，本地研发环境部署等都需要有相关的人员提供能力。这部分的开发工程师更关注基础设施的层的能力建设，我认为包含了刚才说的几个大类能力，包括容器建设、IDE建设、研发的工作流平台相关的能力建设。这部分的开发工程师更多要对c++/swift/java等语言要有更多的了解，对编译、渲染相关的知识要有更深入的理解，通过完善应用开发工程师所使用的端研发设施和端运行时环境，大幅减少应用开发工程师所需要的知识。
同样举个例子，大家在端侧容器如Flutter侧研发的过程中，有对应的组件库和API能力的前提下，应用开发工程师不需要了解不同操作系统之间的差异。同样在环境部署上，本地环境部署和分支管理的一站式工具将屏蔽不同工程（iOS/Android）的依赖更新、构建等问题，应用开发工程师专注在Dart侧或TS侧的编译构建和调试上即可。当然这是一个相对理想的假设，实际在推进过程中基础设施的建设可能要以3年为周期持续迭代，同时两个岗位需要可以高效的相互协作。
2. 端侧配套能力的再升级
岗位设计背后的需要有配套的能力建设，正如上一章提到的，能力建设的本身是降低上层研发交付的门槛，我认为能力侧会从以下几点能力开始建设。
统一的端侧容器能力
端侧容器这里指的是如Flutter/RN/Weex/小程序等具体的能力实现，一般包含渲染引擎+上层的虚拟机，我们常见的Webview也是端侧容器的一种，对于现代App来说，端侧内置各类容器完成不同的业务场景的目标是非常常见的事情，举例子来看，淘宝的双十一会场由Weex承接，带来较好用户体验的同时，减少了消费者原有在Webview内的加载渲染等待的时间，提升了流畅度，也帮助了业务转化率指标的显著提升。小程序在微信和支付宝场景下为业务引入了丰富的外部生态并保障了基础体验和安全性。但是随着业务的迭代和不同场景的接入，端侧容器在App内部一般会有多个，不同场景下容器与容器之间的交互成本较高，多个容器在运行时环境下的内存消耗较大对稳定性和问题排查都造成了更多的问题，在复用上，跨容器之间的组件复用难度较大体验难以一致。这都是现有场景下的问题。
从这个角度来看，新的端侧容器能力更多强调统一，这里我给出一个定义：端侧80%以上的代码及应用场景使用同一个容器。统一容器带来的架构上的同构有复杂度低、分层可替换、性能提升、可维护性提升等众多优势，下一章提到的KUN的建设，就是我们以Flutter为技术基座的一种实现。同样举例说明：极限情况下当一个App全由Flutter或RN进行构建和研发的时候，我认为该App就具备了统一的端侧容器的能力，但关键在于，该容器是否能在更大规模的重视体验的C端产品上使用，而不是在长尾App中进行应用。不同的规模和业务要求下的技术挑战可能完全不同。
统一的编程平面
统一编程平面包括了研发侧使用的IDE、配套的DevTools、统一的API和组件库以及配套文档。这里的统一是指在应用开发这一侧，面向Dart和TS两种语言，对应相关设施应该尽量是一套或在描述上完全一致。举例说明，一位应用开发工程师可以通过Dart调用我们已经实现的【价格选择器】的组件，同样也可以通过TS的调用使用我们已经实现的【价格选择器】组件。而维护该组件的同学在开发之初就会提供一套在Flutter侧的实现，但提供两套接口（Dart/TS）。显然这种场景下真正做到了技术侧的完全复用，大家在一套长期可以共建的标准下补充API和组件能力。如果单纯从客户端的视角来看，这种方式通过【标准】来约束客户端形成长期稳定的组件库，从Web前端的角度来看，这种方式沉淀了可扩展的组件库，减少的Web前端的工作量的同时又大幅提升的端侧的用户体验。换言之统一的编程平面在容器之上给予支持，在需要提供标准的时候提供标准，在需要扩展的时候给予更轻量级的扩展能力。让研发的体验和效率同步提升。
对于统一的编程平面的畅想来看，未来的应用开发工程师可能需要在一个IDE下进行开发，无需再在多个IDE进行切换。同样DevTools中对App以及对应JSBundle的部署工作都会抽象成一些常见的命令，通过CLI的方式显著减少大家的环境配置和切换的时间。在API和组件库的建设中会有相对完善的准入机制和所见即所得、文档自动化生成的站点来保证不同知识背景下的客户端或者前端工程师顺利转型为终端应用开发工程师，同时面向Dart和TS生态进行问题排查或者业务代码研读的时候，由于标准一致，成本会进一步下降。
统一的研发工作流
在端侧的研发工作流中，客户端原有的研发工作流是典型的面向整包的构建和发布，有独特的研发到集成再到测试回归验证以及上线灰度的流程，另外客户端伴随着应用商店的审核，整体节奏更慢，由于无法做线上的变更，对稳定性的要求更高。而前端的研发工作流更多是面向页面级别的代码构建，无需集成直接回归验证再到线上灰度，整体节奏更快，但由于是全量的线上代码覆盖，兼容性和稳定性会稍差。面向未来的研发工作流，我认为一方面要解决交付效率的问题，另一方面对稳定性也要有所保障。
从之前的岗位分工来看，我认为面向上层的应用开发工程师更多应该使用基于DailyBuild的线上工作流，该工作流的特点是在合规的条件下相对频繁的进行工作流的变更和部署，使得线上的关键链路可以进行快速的AB和迭代。而面向基础设施的开发工程师更多的会在Weeklybuild中更新端侧的容器能力，使得容器侧的问题得到快速的响应和收敛。当然在研发工作流之外，我们需要考虑上层部署侧的降级逻辑、工作流内部配套的持续集成和自动化测试能力等等。Anyway，研发工作流通过数字化和自动化的方式服务于两个研发角色，在可观测、显著减少人为因素犯错的同时显著提升整体的交付效率。
接下篇：https://developer.aliyun.com/article/1225904?groupCode=idlefish
