关于flutter:下一个-Flutter-项目要记住的-11-件事

原文

https://medium.com/flutter-co…

注释

创立一个新的 Flutter 我的项目是一件坏事ーー陈腐的代码库、没有遗留代码(还没有)、空安全性、您最喜爱的软件包的最新版本等等。然而与此同时，您应该在我的项目开始时做出要害的决策，这些决策将为将来奠定根底，例如工具、包、文件构造、状态治理解决方案、测试计划。否则，这个我的项目最终会变成另一碗意大利面和肉丸。为了防止这种状况，我筹备了一个列表，在我看来，这个我的项目中最重要的元素应该尽早决定。我心愿它能帮忙你，因而ーー高兴的浏览！

1. 动态程序剖析

I will not write messy code (我不会写乌七八糟的代码(source 起源)

Linter 是一个动态剖析工具，用于辨认和标记代码中的编程谬误、正告和款式缺点，以便您修复它们。在 Flutter 上下文中，这是最容易实现的货色之一，也是放弃代码洁净的最有用的货色之一。

有很多不同的规定能够让你的代码遵循，然而我倡议你应用一个事后定义的规定，它曾经遵循了基于 Dart 款式指南的最佳实际:

https://dart-lang.github.io/l…

https://dart.dev/guides/langu…

• lint;
• flutter_lints Flutter;
• very_good_analysis.

无论抉择哪个包，都能够在 analysisservices \_ options. yaml 文件中增加或删除任何特定的动态剖析规定。

2. 本地化(l10n)

本地化 [起源](https://marcosantadev.com/wp-…

什么是本地化(简称 l10n)？

本地化是对产品或服务的调整，以满足特定语言、文化或冀望人群的“外观和感觉”的须要ー TechTarget

建设一个用户感觉天然的应用程序是必要的，例如应用正确的翻译、日期和货币格局、文本方向。因而，本地化是一个根本的工具。即便您正在构建单个区域 / 语言应用程序，我依然建议您尽早实现本地化，从而将文本与 UI 代码拆散开来。因而，能够在不影响代码的状况下对它们进行重用和调整。

Flutter documentation 精美地解释了国际化应用程序的过程。如果缺省形式看起来太简单，或者您须要一些有用的扩大和帮忙器办法，那么有一些风行的第三方包，比方 easy_localization，能够帮忙您实现本地化过程。

3. 环境(有一些滋味)

Programming environments 起源

我敢打赌，当有人在生产中损坏数据或删除整个用户表时，您至多曾经从您的环境中据说过一个案例(没有双关意思)。置信我，这一点也不好玩。因而，为你的我的项目创立不同的环境是一个很好的实际:

(本地)环境ー用来让你抓狂: 在代码中做试验，间接在数据库中更改数据，应用快捷键并硬编码认证标记或提供模仿数据。玩得开心，并提供这些性能

• 帮忙您验证代码中的更改，用“实在”数据 (通常在这种环境中应用生产数据快照) 测试个性，并在将应用程序公布到生产环境之前验证它。如果你的团队中有质量保证工程师，这就是他们发光发热的中央
• 环境ー由实在用户应用的环境，其中数据损坏是不可承受的(请始终进行备份)

领有这样的环境能够帮忙您在这些更改达到用户手中之前平安地试验和验证个性。

当初，另一个局部——滋味。不，不，咱们不是在探讨甜的、咸的或酸的货色ーー这只是在编程中用来形容应用程序的不同构建变体的另一个术语。例如，您心愿使图标和题目、API 端点或任何其余配置对于每个特定环境都不同。为此，您须要定义一种不同的“滋味”，这种滋味在为特定环境构建应用程序时应用。这里有一些对于如何为 create flavours for Flutter。

4. 继续集成和继续交付

继续集成阶段 (CI) 和继续交付集成阶段(CD)source 起源

在引入不同的环境之后，自然而然的下一步是自动化构建、测试和公布应用程序的过程。CI/CD 自身就是一个相当简单的主题，无论如何我都不是这个畛域的专家，因而我倡议搜寻一些对于如何使利用程序开发的不同阶段自动化的其余资源。

然而，有很多 NoOps 解决方案是与 Flutter 兼容的，所以你能够轻松自动化你的开发过程:

• Appcircle;
• Codemagic 代码魔法;
• Bitrise;
• VS App Center (还没有 Flutter 集成，然而有一些资源能够帮忙你设置所有的货色)

这些解决方案中的任何一个都能够解决问题ーー简略地说，抉择一个合乎你的须要和估算的计划。

5. 后端代码

(另一个对于后端的迷因(source 起源)

您是否曾经用任何非凡的或者不那么花哨的编程语言实现了后端？很好，您能够跳过这一步，但我依然建议您查看一些云解决方案，以供未来参考。

在简化版本中，应用程序的后端局部有两个选项:

1. 应用您喜爱的任何编程语言和框架实现自定义后端解决方案，然而稍后将解决所有 DevOps 让你的代码和数据能够从应用程序中拜访
2. 应用任何云解决方案来减速开发过程，并将大部分 DevOps 留给云供应商

如果你感觉第二个抉择很有吸引力，能够从反对 Flutter 的云平台中抉择一些:

• Google Firebase 谷歌 Firebase;
• AWS Amplify;
• Supabase 女名男子名;

云平台为您的应用程序提供身份验证、数据库、存储、API 选项和许多其余个性。如果您只须要验证这个想法并疾速构建 MVP，而不须要破费大量工夫在成熟的后端解决方案上，那么上述任何一个都是一个很好的抉择。

6. 日志记录，解体数据和剖析

(哎呀，出问题了 source 起源)

伐木被低估了ーー在这里，我说过了！所有都很好，直到呈现问题，你须要理解这方面的信息。当咱们探讨什么应该记录，什么不应该记录时，总有一个灰色地带。但有一件事件始终是明确的: 您必须晓得应用程序何时解体以及问题的起因。你收集的对于这个事件的数据越多，就越容易发现和解决这个问题。

像 Sentry, Firebase Crashlytics, Datadog、Datadog 这样的服务能够帮忙你记录最重要的数据、解体报告，甚至在你的应用程序或相干服务呈现故障时设置告诉。

另一种类型的日志记录是收集用户数据用于剖析目标。当您构建一个全新的、可能是一流的产品时，理解用户的需要、他们的行为以及他们如何应用应用程序是至关重要的。为此，各种剖析工具能够集成到您的 Flutter 应用程序，如 Firebase Analytics 剖析，App Center Analytics 核心剖析和许多更多。

7. 应用程序 branding

Material theming (Material 主题化(source 起源)

任何应用程序或品牌的次要指标之一就是取得认可。应用正确的色彩调色板，标记，图标，设计元素，内容，字体，有时甚至布局使你的产品怀才不遇。这就是应用程序的品牌化，在开始的时候筹备好根本的局部将会在整个我的项目中节俭你很多工夫。

如果你曾经筹备好了你的 UI 原型或者设计组件，当初是时候把它们转移到你的应用程序中并定义主题 —- 色彩、字体、形态等等。为了不便起见，一个叫 Mike Rydstrom 的好人为这个 flex_color_scheme 计划创立了一个杰出的包。

8. 我的项目构造和状态治理

(Flutter 状态治理(source 起源)

是的，有争议的那个。须要廓清的是，基本没有所谓的“最佳国家治理解决方案”或“最佳应用程序架构”——如果有人不这么认为，请记住，他们可能也会先把牛奶倒进碗里，而后再倒麦片。这是最蹩脚的局部ーー我不能教你最好的办法。我只能提供几个选项或分享我的偏好。

下一个 Flutter 我的项目的几个文件构造选项:

• Clean Architecture 清洁的修建 — ー清晰的关注点拆散，是否短暂存在。诚实说，我不喜爱这样。我感觉这个概念中有太多的形象，可能会减缓开发过程
• Layered Architecture 分层修建 ー依赖于将数据、业务和示意逻辑分为不同档次的想法。这样的文件构造对于中小型我的项目来说工作得很好，然而我感觉当我的项目增长时，这些层会变得越来越不堪重负
• Modular Architecture (I have described this concept 模块化体系结构 (我曾经形容了这个概念 here 这里) ー把程式码宰割成不同性能的模组，以便不同的模组相互作用。这是我最喜爱的一个ー它与团体国家治理解决方案(TEAM BLoC，YEAH!) 顺利地工作对于大型项目来说，规模很大。然而，它也带来了一些挑战，比方公共逻辑放在哪里，不同的模块应该如何通信等等

对于《Flutter》中的国家治理问题，我想咱们曾经到了能够把整个会议都用来探讨这个问题的时候了，然而预先还没有最初的答案。我只想补充一点，抉择一个你感觉最舒服的。你能够在 here 找到一个全面的选项列表。

9. 代码生成

Code generation (代码生成(source 起源)

如果您想简化一些步骤并节俭一些开发工夫，您能够在我的项目中应用代码生成。少编码，多交付！Code less, deliver more

有一系列不同的工具能够应用，无论是解决本地化、资产、解析 JSON、生成模型类、实现服务定位器、路由，还是解决不可变状态。惟一要做的就是考察可用的工具和包，并抉择最好的工具和包来满足您的我的项目需要。

对于一个疾速 Flutter 我的项目启动，我倡议查看出 Very Good CLI。这将节俭您几个小时的配置(可怜的是，我曾经学会了艰巨的形式)。

此外，上个月我还做了一个对于 code generation 的演讲ーー它可能是 Flutter 代码生成旅程的终点，所以看看吧！

10. 测试策略

Application testing (应用程式测试(source 起源)

用测试来笼罩 100% 的代码是好还是坏？当然，这很棒，然而代价是什么呢？这样想的话，您可能会掉进一个注定要陷入困境的深渊，在那里您破费更多的工夫编写测试，而不是开发个性。为了防止这种状况，您须要一个测试策略。

不要误会我的意思ー用测试笼罩代码是一件坏事，而且代码中越荫蔽的中央，在实现新个性时就越平安。只是，在我看来，与编写测试所破费的工夫相比，您应该找到测试依然为您带来更多价值的平衡点。例如，这是我的测试策略:

• Business logic (services, repositories, BLoCs) should be covered 85-100% in 业务逻辑 (服务、存储库、集群) 应该在unit/integration tests 单元 / 集成测试 ー这是所有应用程序中最重要的局部，因而我看到了测试的很大价值;
• Widget tests 小部件测试 应该蕴含所有可重用的 UI 组件。当单个组件被正确测试时，您能够开始测试单个屏幕，然而不要太具体
• End-to-end tests 端到端测试, 涵盖了次要的应用程序流以及与 UI 的交互。没有深层次的魔法ーー只是经验一些要害的工作流程。它们蕴含的屏幕越多越好
• 当整个用户界面准备就绪并实现时ーgolden tests 黄金试验 确保 UI 不会受到当前更改的影响

诚实说，我依然在测试中寻找中庸之道，然而置信我，你会在一个又一个我的项目中做得更好。

11. 自述文件

Make a README (自述文件(source 起源)

你没听错，文件。README 文件是我的项目中最重要的文档，尤其是在团队中工作时。

您是否刚刚引入了一个须要代码生成的新解决方案？您是否刚刚增加了一个有用的 bash 脚本来主动实现这个过程？您是否实现了一个必须在我的项目中的任何中央应用的全局记录器？咱们无奈读取你的思维ーー在 README 文件中提到这一点！

没有太多的文档 (至多我没有遇到过这种状况)，只有不足对于我的项目和代码的信息。所有生成、测试和运行代码的命令、各种文件构造决策、图表、内部工具和服务、对于不同环境的信息(没有 SECRET KEYS) 都应该放在这里，并保留在一个独自的中央。这是一个无聊的工作，但却是一个十分有价值的工作！

Phew, what a ride… (这车真不错 … .source 起源)

就是这样! 谢谢你花工夫浏览这篇文章。

我错过了什么吗? 在评论中提及吧! 在构建一个新的 Flutter 应用程序时，你的清单是什么？

© 猫哥

• https://ducafecat.tech/
• https://github.com/ducafecat
• 微信群 ducafecat
• b 站 https://space.bilibili.com/40…

往期

开源

GetX Quick Start

https://github.com/ducafecat/…

新闻客户端

https://github.com/ducafecat/…

strapi 手册译文

https://getstrapi.cn

微信探讨群 ducafecat

系列汇合

译文

https://ducafecat.tech/catego…

开源我的项目

https://ducafecat.tech/catego…

Dart 编程语言根底

https://space.bilibili.com/40…

Flutter 零根底入门

https://space.bilibili.com/40…

Flutter 实战从零开始 新闻客户端

https://space.bilibili.com/40…

Flutter 组件开发

https://space.bilibili.com/40…

Flutter Bloc

https://space.bilibili.com/40…

Flutter Getx4

https://space.bilibili.com/40…

Docker Yapi

https://space.bilibili.com/40…