混合拉普拉斯和混合高斯_你应该去混合吗？

最新推荐文章于 2024-09-25 10:59:43 发布

dfsgwe1231

最新推荐文章于 2024-09-25 10:59:43 发布

阅读量215

点赞数

文章标签： java python 大数据编程语言数据库

原文链接：https://hackernoon.com/should-you-go-hybrid-138e9810a9db

版权

混合拉普拉斯和混合高斯

首先，我先说说我是基于html / web的移动应用程序的支持者，然后再变酷。当它不是一个好主意时，我想把它做回来-工具太笨拙了。我告诉我的（移动）经理，我们应该只做基于Web的移动应用程序，他苦笑着问我为什么要质疑他做出的每个决定。

现在，我经验丰富了，我仍然认为与您的移动应用程序混合使用是个好主意，但我认为大多数人都被误解为错，并且/或者出于错误的原因而做。人们犯的错误是，这与流行语无关。这与切换到Cordova或Flutter或React Native或Xamarin或任何特定框架无关。

在不同客户端之间共享代码的正确方法是将它们分解为小块，以减少级联的破坏。您需要使用组件化的体系结构，并使用版本化的包来导入代码，以便不必一路更新客户端。

背景

我曾经在一家企业产品公司工作，他们在那里有非常大的软件套件，这些软件套件基于本地部署（还提供了云托管选项，这使其成为“混合”产品。）25年来，产品代码库变得很大。经过数百万美元的开发和测试时间，该软件的新版本大约每年发布一次。新版本通常仅包含少量标题项，并与其他一些维护工作和少量改进捆绑在一起。

由于所有共享代码和共享基础结构，维护大型产品可能是一场噩梦。简单的更改可能需要很长时间才能完成复杂的新功能。这是因为可以将新功能分离为微服务或单独的存储库，以避免过去的错误。对旧功能的升级将导致需要进行级联的交叉测试。需要一个庞大的质量检查团队来测试一系列模块中的细微更改，其中一些是真正不知道的，甚至没有开发人员负责。

每次将“代码共享”作为主要优先事项时，都会发生这种相同的权衡。如果您尝试通过包装Web应用程序来创建移动应用程序，则对网站的简单更改现在会破坏该移动应用程序，反之亦然。

自动化测试可以解决这个问题吗？不完全是。如果您为所有客户编写自动化测试，并在CI中运行它们，则您将知道何时进行了无效的代码更改。这将有助于防止产生的错误（会有很多）进入生产环境。但是作为交换，您将仍然要花费大量的工作时间才能进行通过所有测试的更改。自动化测试可以帮助您的客户，但他们实际上并没有采取任何措施来帮助您的工程师。您还将浪费时间编写测试。请记住，对于Web /移动混合应用程序，我们谈论的是UI测试，它通常是最昂贵且维护繁重的。

了解流行语

在评估最新技术时，您必须尝试弄清楚该技术真正针对的是谁，以及如何与您当前的职位进行比较。

时髦的技术倾向于支持创业文化。他们偏爱允许您创建快速概念验证工作的工具。快速迭代，快速失败。从长远来看，这些技术自然会导致更高的维护成本。它们是债务融资的一种形式。这个想法是，如果产品出现故障，您将无须支付长期维护费用。

以Apache Cordova为例。 Cordova让您可以将您的网站打包到一个移动应用程序中。利用该技术，您可以创建网站，然后去找老板，客户或投资者，然后说“我们有一个移动应用”。但是，由于本文前面所述的原因，从长远来看，这会使您减速。您正在尝试一次共享所有代码，因此现在您需要开始将针对不同平台的更改塞入同一代码库。您需要各种方式的动态开关，切换器，表格等。Cordova是通往许多公司发现的最糟糕的共享代码地带的最短路径。

不过，有趣的是，您可能已经点击了这篇文章，因为您正在考虑“切换到Cordova”。例如，“切换”已经有一个移动应用程序，但是您想使其成为Cordova应用程序，因为您认为这可能会降低成本。冒着听起来像是唱片破损的风险，我告诉你相反的情况将会发生。与维护单独的应用程序相比，您的成本将增加，迭代速度将下降，就像我的老公司有数百名工程师需要一年才能交付少量升级一样。两次尝试使用相同的源代码会降低短期成本，但会增加长期成本。也就是说，除非您以正确的方式进行操作。