下一個 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...

無論選擇哪個包，都可以在 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 來源)

您是否已經用任何特殊的或者不那麼花哨的程式語言實現了後端？很好，您可以跳過這一步，但我仍然建議您檢視一些雲解決方案，以供將來參考。

在簡化版本中，應用程式的後端部分有兩個選項:

使用您喜歡的任何程式語言和框架實現自定義後端解決方案，但是稍後將處理所有DevOps 讓你的程式碼和資料可以從應用程式中訪問
使用任何雲解決方案來加速開發過程，並將大部分 DevOps 留給雲供應商

如果你覺得第二個選擇很有吸引力，可以從支援 Flutter 的雲平臺中選擇一些:

雲平臺為您的應用程式提供身份驗證、資料庫、儲存、 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 不會受到以後更改的影響

老實說，我仍然在測試中尋找中庸之道，但是相信我，你會在一個又一個專案中做得更好。