搬迁很难, 但从头开端很简略

从Flutter的测验版开端, 我就一直在关注它, 从那时起, 我就看到了Flutter在开发者, 社区和公司中的选用. 大多数新兴开发人员都曾多次评论过这个问题:

为什么大公司不运用 Flutter?

因而, 这篇小文仅仅我对这个问题的个人调查和回答.

转向新技能既困难又复杂, 而从最新技能重新开端则很简略. 这(据我调查)也是为什么安稳的大公司不会将其长期运用的应用程序搬迁到新技能的最大原因之一, 除非它能带来惊人的利润.

你会发现大多数草创公司都在运用 Flutter, 这是由于 90% 以上的跨平台应用程序新构思都能够在Flutter中以经济高效的办法轻松实现. Flutter中的一切都十分快速, 令人惊叹, 并且具有咱们在曩昔几年的Flutter之旅中听说过的一切令人惊叹的长处.

那么问题来了:

既然Flutter如此令人惊叹, 高性价比, 单一代码库, 更轻松的单一团队办理, 令人愉悦的开发者体会, 等等等等; 那么为什么大公司不将他们的应用程序搬迁到Flutter呢? 从头开端搬迁或重写, 具有单一团队, 单一代码, 这不就是天堂么?

不, 没那么简略.

问题所在: 事务vs技能热情

Flutter 令人惊叹, 你最终能够压服开发人员在公司中运用Flutter构建应用程序. 问题在于公司的运营事务. 企业期望Flutter能立即为事务做出贡献. 他们不期望等候自己的团队彻底重写应用程序, 然后将其付诸实践以繁荣事务.

但正如我前面所说, 关于技能团队来说, 重写是最理想的. 因而, 这是一个能够由公司利益相关者共同考虑的问题. 公司内部需要在分析范畴, 事务类型, 团队文化等一切因素后, 找到一个中间态度.

无论怎么, 让咱们来看看这两种状况的结果怎么.

从头开端重写: 技能方面

一家大公司具有庞大的产品, 这些产品已融入流程和范畴, 作业完美无瑕, 为企业完成了作业.

从技能上讲, 对首席技能官来说, 最好的办法是在Flutter上从头开端重写应用程序, 并将其完成. 但是, 假如他们决议这样做, 就有必要雇佣一个全新的Flutter开发团队, 向他们解释当时产品/范畴的一切状况, 并让他们重写应用程序. 这看起来很简略, 其实不然. 当时代码库中有许多内部常识有必要传授给新团队, 这样他们才能为应用程序构建彻底相同的体会/UI/UX/流程.

为什么构建彻底相同的东西如此重要?

这是由于用户总有一天会第一次收到Flutter构建的应用程序更新, 这关于一个具有不计其数用户的应用程序来说是十分风险的.

其次, 新功用正在当时应用的根底上构建, 重写后的应用或许无法赶上当时应用. 但这是一个商业决议计划(是中止新开发并先进行重写, 还是继续在当时应用程序中添加功用, 无论怎么都要权衡利弊).

每家公司在范畴, 文化, 人员, 领导力, 思维过程, 智囊团等方面都是独一无二的. 内部或许存在数以百计的应战, 只要进入体系后才能了解. 你不或许对每家科技公司都提出一个单一的观点.

从头开端重写: 事务方面

公司在选用新事物时, 有一个十分重要的想法:

在重写的过程中, 事务不仅不应受到影响, 并且还应保持增长.

这意味着你不能在运转中的应用程序的功用和开发上退让. 在重写版本中, 运转正常的程序不应呈现过错. 为保证这一点, 需要进行严格的原子级测验, 以保证用户从一开端就把握的功用不会呈现任何问题(咱们议论的是大公司, 这意味着应用程序已运转多年). 咱们能够进行单元/集成/用户界面测验, 但当它关系到事务, 金钱和用户时, 没有人会愿意冒这个险.

简而言之, 大多数安稳的公司不会决议从头开端用Flutter重写他们安稳的应用程序. 假如是根据项目的公司, 他们或许会运用Flutter启动新赢得的客户项目.

搬迁(事务上友爱, 技能上却不友爱)

公司决议搬迁到Flutter的另一种办法是逐屏搬迁到 Flutter, 并运用与本地端(Talabat 的应用程序)通讯的办法渠道. 关于技能团队来说, 这或许是一场噩梦, 但关于事务的继续运转, 以及让Flutter部分从一开端就为事务做出贡献来说, 这是最可行的办法(在重写过程中, 应用程序的Flutter部分除非上线到出产, 不然对事务没有任何用途).

作为一名读者和Flutter爱好者, 你或许会认为逐屏搬迁十分了不起, 但实际上, 当你在一个每天有不计其数用户运用的出产应用程序中作业时, 这真的十分复杂. 这就像开颅手术.

总结一下

根据我的调查, 关于一家以产品为根底的公司来说, 决议将自己多年的移动开发技能栈转换为新的技能栈是十分困难的. 因而, 假如大公司真的决议转换, 这个决议自身的确值得称赞, 勇气可嘉, 也很有激励效果.

假如事务十分重要(如 Talabat, Foodpanda, 或涉及日常很多运用, 支付, 安全, 多供货商体系等的用户关键型应用程序), 那么从事务角度来看, 最理想的做法是以混合办法渐渐搬迁应用程序. 相同, 这也不一定对一切人都可行, 重写或许更好. 这彻底取决于公司和事务的结构以及决议计划的力度.

关于以项目为根底的公司来说, 运用Flutter启动新项目是最理想的选择(由于他们具有热情洋溢, 不断强大的团队, 并致力于融入新技能). 当他们运用Flutter构建新项目时, 假如交给速度比以前更快, 效率更高, 他们就会主动扩展事务.

关于开发人员和技能团队来说, 任何新技能都是令人惊叹的, 但假如你是一位在结构合理, 安稳的公司作业的工程师, 你也应该了解公司的事务视角, 从而理解他们对转用新技能的观点.

假如你是一名高级工程师/资深工程师, 你应该用他们更简略理解的语言向事务部门传达你的热情. 关于推介 Flutter, 能够是更少的时刻, 更少的成本, 更少的努力, 更快的交给, 一个团队, 一个代码库, 更少的公关检查等(假如你是Flutter人员, 你已经知道了一切这些).

事务部门在做决议时有必要考虑多个方面, 因而作为工程师, 要告知他们一些能让他们更简略做出决议的工作.

以上是我的个人观点和观点, 假如你有不同的观点或经验, 请随时在评论中与我共享, 很乐意参加该问题的评论.

Stay GOLD!