混合开发之殇

序言

今年（2020年），以混和合作开发控制技术驱动力的销售业务形态之战变的四起，为此，其反之亦然造就了很多著眼于化解格朗普雷县合作开发的构架。这首诗主要从文化史产业发展出发，并单纯讨论许多不同层次的许多混和合作开发控制技术。最后，单纯探讨在一个组织中，如何展开合理的控制技术重大决策，以期助推销售业务的产业发展。下面，若不强调宾语，则其专指混和合作开发。

概要：

文化史产业发展

以铜为镜，能正汉官；以史为镜，能知无宗；理学家，能明利害。

这里，我按照时间次序，对那些控制技术再次出现的原因及化解的难题单纯地归纳如下表所示：

2011年 WebView Hybrid（如前所述WebView的混和合作开发）

最早将web控制技术应用领域如在植物合作开发再次出现在2009年，其代表者性乙醛是PhoneGap。2011年，PhoneGap开放源码，并将其重新命名为Cordova。从此，该控制技术进入德国大众的视线。随著该控制技术的产业发展，也渐渐再次出现了如前所述该控制技术的构架和自然生态。当中，比较有名的是Ionic。在此之前的几年，亚洲地区的很多B2C也对此类控制技术展开了投资，但又各不相同，当中包括淘宝网、携程、德国大众、米饭等。

2015年 Native Render（如前所述原生植物图形的混和合作开发）

后端控制技术的产业发展，2013年渐渐再次出现了ReactJS、VueJS等多种后端构架。随著那些构架的产业发展，使得如前所述那些构架的跨端图形成为了可能。其代表者乙醛为2015年再次出现的React Native，亚洲地区的穆萨也对该控制技术展开了介入，并研制了如前所述VueJS的WEEX。这种如前所述原生植物图形的构架的确能够带来接近原生植物应用领域的使用者新体验，但其昂贵的成本另很多小公司却步。

2016年 Hybrid Render （如前所述WebView的混和图形）

在WebView图形和Native图形的危机重重中，问世了混和图形。其基本原理是透过在WebView其内全面覆盖几层原声带模块，以期突显WebView更多的能力。其代表者乙醛是QQ小流程，随著QQ小流程的产业发展和其亮眼的成就，反之亦然也造就了更多供应商的介入。那些介入也导致了其碎片化的激化。为了化解碎片化的难题，易于2018年问世了快应用领域。

产业发展的主旋律

透过上面的产业文化史，我们能归纳出来许多关键的信息。

如果读者能够接受以上观点，那么，我们就能从这几个观点推导出一个结论：现阶段，混和合作开发的前景依旧不够明朗。

那既然混和合作开发前景不够明朗，那么，我们就需要对混和合作开发产生的背后原因展开分析，并在那些混乱工具中选择适合我们的，并用其构建可持续的销售业务。

蓝图

让我们回到2011年，来重新审视一下混和合作开发最初了意图，并从那些意图来推出，混和合作开发现阶段的意义：

这是混和合作开发最初的诉求，而为了满足该诉求，现在除flutter外，只有混和合作开发一条路可行。

2. 原生植物应用领域合作开发效率低：

随著原生植物应用领域合作开发工具的完善，人员能力的提升，合作开发效率也在逐步提升。现如今，原生植物应用领域的合作开发效率已经同混和合作开发不相上下。

3. 原生植物应用领域发布节奏慢，维护成本高：

是的，这个难题现在依旧很难化解，不过随著很多应用领域市场默认自动升级，以及各个公司测试体系的建立，该难题逐渐变得不是很重要。

综上，我们归纳一下，混和合作开发化解的主要难题是跨平台，那么，下面，我们将分析一下跨平台是否能节约合作开发成本。

现实

对于任何跨平台方案来说，我们都需要抽象一个中间层，以抹平平台之间的差异。对于Java来说，这个中间层是Jvm，对于QQ小流程来说，这个中间层是QQ小流程运行时。既然这个中间层必不可少，那么它就带来了维护成本。

那么我们如何衡量这个维护成本呢？这里，我选择两个比较重要的点来阐述该难题。

首先，我们从软件工程中的一般过程角度来展开分析。

下面，是一张理想情况下的合作开发过程，也就是不同端的销售业务诉求一致：

从图中我们能看出，在跨平台方案中，我们能够节约的成本仅限于合作开发成本。对于其他过程而言，则无法节约成本。那么，作为一个重大决策者，就需要衡量编码工作在合作开发者的工作时间中所占的比重，以及编码工作者在软件合作开发的整体过程中所占的比重，然后才能够得出一个理想情况下，能够节约的成本。

对于非理想情况，比如，我们在销售业务上，有页面或功能需要在不同平台上体现出许多差异性，或者，由于其平台本身的差异性而要对跨平台中间层本身做修改，那么，这时候就带来了许多新的成本难题：

其次，我们从软件工程的工程工具角度来展开分析。

我们平常所看到的软件合作开发，只是软件合作开发中的冰山一角，而更多的精力会投入到许多工具的维护，比如构建、打包、监控、统计、日志等。对于那些工具，格朗普雷县的维护成本是必不可少的，甚至，在引入混和合作开发后，我们多了一端的维护成本。

最后，说了这么多，笔者无非是想表达一个观点，就是混和合作开发没有想象中那么美好。看到了那些，如果你还是想要继续展开混和合作开发之旅的话，那么，下面将给出许多需要考虑的点。

重大决策

如果能够从销售业务上分析得出，平台本身提供的能力已经足够丰富，并且预期未来几乎没有扩展本身跨端工具的需求，则适合采用混和合作开发工具。

2. 是否需要第一时间介入不同平台提供的不同能力？

比如iOS提供了VR/AR的能力，而混和合作开发工具本身并没有及时介入，销售业务上是否有很强烈的需求第一时间介入，如果需要，则不适合使用混和合作开发工具。

3. 是否对质量有极为苛刻的追求？

因混和合作开发引入了不同平台的抽象层，这意味着许多不稳定的因素，如果销售业务上对质量有很高的要求，则不适合使用混和合作开发控制技术。

4. 是否有足够的资源，持续改善混和合作开发中的基础设施，并推动开放源码社区的成长？

因现有的混和合作开发控制技术很多都为开放源码软件、或其他公司维护的闭源软件，那些软件都需要合作开发者的反馈来展开更新。因此，在使用过程中难免难题较多，需要持续的资源投入，才能够发挥其最大的价值。因此，这种合作开发方式比较磨练合作开发者的耐心。

5. 是否能够展开组织结构的变革，并具有相应的人才储备？

因混和合作开发往往涉及格朗普雷县的不同特性，需要多种不同类型的人持续交流，以期能够对基础能力展开良好的封装。当中，基础能力、销售业务诉求、合作开发效率，三者存在千丝万缕的联系。为了优化这三者之间的沟通成本，其会促成传统方式（以不同端做为划分依据）大相径庭的组织划分方式。这不仅影响着组织结构，还影响着对人才的能力要求，这种能力要求也要高于传统的方式。综上，若重大决策者能够意识到所面临的挑战，并能够有途径、有信心化解那些难题，则能采用混和合作开发控制技术。

引言

本首诗主要采纳了airbnb在react native方向的经验教训，并结合了ThoughtWorks在react native中踩坑较多的赵林的许多观点，还有笔者在混和合作开发方面的思考归纳而成（但本文不代表者ThoughtWorks的观点）。笔者本身非常肯定不同公司在混和合作开发上的努力，当中RN和快应用领域的再次出现令人兴奋，其他的许多工具也为社区带来很多活力。

最后，对于本文观点，若有任何疑问及观点，欢迎在评论区交流。