Flutter 团队

在 2019 年组建 Flutter 团队会面临一些挑战

  • Flutter 尚属新事物，尽管其声誉日益增长，但尚未得到充分确立。组建 Flutter 团队意味着您和您的同事都在押注一项新技术。
  • 很难找到在 Flutter 方面有丰富经验的人，即拥有多个已运行一段时间的实际项目经验。您很可能需要在一个没有经验丰富的 Flutter 领导的团队中进行组建。
  • Flutter 开发的架构和实践正在不断涌现。在这个阶段，很难对各种方法进行评估。这使得建立首选实践变得更加困难，并可能意味着初始项目会采用截然不同的架构方法。
  • 您必须确保能够为您的团队提供源源不断的好项目。闲置的团队往往无法长久地保持在一起。他们需要技术挑战、需要构建的真实产品，最重要的是，需要将产品发布给用户。

手册

在我们的项目中，移动应用程序通常会涉及许多方面。我们正在将这些方面整理成一份手册，作为团队构建 Flutter 应用程序时的参考。

该手册会引用文章、pub.dev 上的软件包、我们已编写的代码以及 Flutter 文档。目标不是创建单一的架构，而是绘制出可用的 Flutter 知识和方法，以便我们能够尽快进入主题。最终，我们以及 Flutter 社区可能会倾向于首选的实践。

手册具体包含哪些内容？例如处理不同布局（纵向与横向、手机与平板电脑）、集成推送通知、本地存储、应用程序状态、API 集成、多平台构建、模块化应用程序、CI、测试等等。

专注与专业化

为了尽快提高团队的效率，我们决定采取“分而治之”的策略。这意味着我们创建了 3 个知识轨道

  • 布局与 UI — 与构建应用程序 UI 相关的主题，包括管理多种布局、平台差异、动画和用户交互。
  • 数据与 API 管理 — 在不同场景下调用 API（例如 REST vs GRPC、流式数据等），在应用程序中管理数据（例如 Bloc、Provider 等），以及与 UI 的集成。
  • 横切性主题 — 这是我们的“其他”类别，包括 CI、编写插件、处理深度链接、推送通知等。

该方法是让团队成员一次专注于一个轨道作为专业领域。一旦我们觉得对当前轨道有了足够的了解，就会轮换轨道。

宣传

在 Snapp，我们对技术充满热情并持有鲜明的观点。这会引发关于我们使用的技术的一些健康友好的辩论。作为一个倡导一项尚未拥有长久成功记录的新技术的团队，这意味着我们必须成为宣传者。

宣传对团队来说可以是积极的。以建设性的方式进行时，它会促使团队深入研究一项技术，以便能够向他人解释。对我们的团队来说，这也意味着我们必须从与其他技术的对比以及在其中理解 Flutter。同样，这有助于拓宽我们的知识。

乐趣

团队在一起时保持乐趣总是有益的。这里的“乐趣”不是指胡闹或在办公室玩乒乓球。

我这里指的是技术上的乐趣。具体来说，我们会做一些事情，比如给团队中的其他人出一些小型的编码挑战或技术问题。当以开放友好的方式进行时，我们发现我们会学到很多东西。它还有助于营造一种团队文化，在那里我们可以犯错误（即做错事情），并相信别人会在我们不知道某事时帮助我们。

警告 — 我也见过这种做法以有毒的方式进行，即团队成员试图以此来抬高自己而贬低他人。请不要这样做！
例如，最近一位同事出的 Dart 语言挑战是：从一个句子中提取所有回文词。

实验

在客户项目中推动边界可能很困难。一个未知的框架或未经证实的做法可能会为项目带来不必要的风险。（可以说，在 2019 年使用 Flutter 本身在某种程度上仍然是一项实验。）

因此，我们使用一个简单的项目作为实验的游乐场。例如，我对基于 Flux 的架构如何在 Flutter 中工作很感兴趣。一个实验性项目是尝试此操作的完美场所。

我们在 Flutter 团队选择了两个实验项目。一个是简单的待办事项应用程序——是的，不太新颖。第二个是由 Juhani Lehtimäki 最初为学习西里尔字母而构建的应用程序。