開發一個小型應用程序很簡單。另一方面，開發大規模應用程序極其困難，但至少有大量可用的資源可以指導你。

然而，大多數實際應用存在的中間地帶，卻鮮少受到關注。在軟件開發領域，不陷入過度工程化的陷阱，寫出可維護的代碼的做法，已經越來越少見了。

讓我們探索哪些流行的成分可能對中型應用有益，并評估它們是否會幫助你管理復雜性，或者是否會制造出比解決的問題更多的問題。

Typescript

YES ?

首先，我們來解決這個問題。現在是2023年，對于不在你的開發流程中使用TypeScript，實在沒有任何借口。所有頂級的前端框架都推薦使用它，而且它們的構建過程使得開始使用變得非常容易。

Typescript是JavaScript的超集，它增加了類型注解、接口以及其他功能，使編寫可維護和可擴展的代碼變得更加容易。它可以幫助在開發過程的早期捕捉錯誤，并且可以使得隨著應用程序的增長，重構代碼變得更加容易。

狀態管理

YES ?

狀態管理是任何中等規模前端應用的另一個重要考慮因素。隨著你的應用復雜度的增長，管理狀態變得越來越困難。有許多庫和框架可以幫助解決這個問題，例如Redux，MobX，Vuex和Pinia。這些工具可以幫助你維護一個一致的應用狀態，并使添加新的功能和特性變得更容易。然而，要注意全局狀態會產生耦合，你應該強烈考慮將你的存儲分割成多個模塊。另外，避免濫用它來處理那些不應全局可用的事物，如組件狀態。

功能標志

YES ?

功能標志，也被稱為功能切換，允許我們在運行時和無需新的部署中切換代碼庫中的特定功能。這是一種強大的技術，有助于發布新功能，進行A/B測試，并有效管理開發和部署過程。它們可以帶來更大的靈活性，更快的發布，以及與部署新功能相關的風險降低。有各種庫和工具可用于在不同的語言和框架中實現功能標志。

測試

YES & NO ?

測試是任何應用程序開發過程的重要部分。單元測試、集成測試和端到端測試是一些常用的測試方法，它們可以提高代碼質量，并在長期內節省時間?？蓽y試的代碼通常是更好的代碼，而在開發早期創建測試用例可以確保應用程序會有更少的錯誤，并且在新人加入時會更容易。

另一方面，在大規模應用中，你可能會遇到許多在較小代碼庫中可能并不必要的測試類型。其中包括變異測試、負載測試、壓力測試、性能測試、視覺測試、快照測試等等。

在處理中等規模的應用程序時，找到在編寫足夠的測試以確保穩定性和不過度工程化測試過程之間的平衡非常重要。我們應該專注于創建一個堅實的單元測試和集成測試基礎來覆蓋應用程序。

CI/CD

YES ?

現代軟件開發的另一個重要部分是持續集成和交付。通過CI/CD，我們可以自動化構建、測試和部署過程，節省時間并減少錯誤。使用一個好的CI/CD工具可以使我們的開發過程更高效，并確保我們的應用程序始終準備好進行部署。

領域驅動設計

NO ??

領域驅動設計是一種軟件開發方法，強調對核心業務領域的建模，構建開發人員和利益相關者共享的普遍語言，并根據領域的復雜性設計軟件組件。雖然在具有復雜業務邏輯和多個團隊協作的大型應用程序中，DDD可能非常有用，但對于中型應用程序來說，可能會過度。

對于中等規模的應用程序，簡潔的架構和注重清晰、模塊化代碼的重點往往足以確保可維護性和可擴展性。DDD可能會增加不必要的開銷和復雜性，這可能不會為項目帶來顯著的好處。相反，考慮采用更簡單的架構模式和實踐，以促進代碼組織、關注點分離和可重用性。

Hexagonal Architecture 六邊形架構

NO ??

六邊形架構，也被稱為端口和適配器，是另一種旨在在應用程序的核心業務邏輯和其外部依賴（如數據庫、API和用戶界面）之間創建清晰分離的架構模式。這種分離允許更大的靈活性、可測試性和可維護性。

與DDD類似，實施六邊形架構對于具有復雜業務邏輯和眾多外部依賴的大型應用程序可能是有益的，但對于中型應用程序來說，這絕對是過度設計。

微前端

NO ??

微前端是一種流行的架構模式，它將大型應用程序分割成基于特性或領域的較小、獨立的應用程序。這些較小的應用程序可以獨立開發、測試和部署，從而實現更大的可擴展性和靈活性。

然而，對于中等規模的應用程序，引入微前端可能并不必要，反而可能增加復雜性和開銷，超過其帶來的好處。更傳統的單體架構，結合良好組織的代碼庫和適當的組件使用，可能更適合大多數中等規模的應用程序。如果將來有需要，可以重新考慮過渡到微前端的決定。

CDN

YES ?

使用CDN是一種快速、簡單且成本效益高的方法，通過緩存內容并從離終端用戶更近的服務器提供服務，可以提高您的應用程序的性能和可靠性。

Linting

YES ?

Linting是一種分析代碼以檢測潛在錯誤、不一致性和偏離已建立編碼標準的過程。這是一種維護代碼質量、提前捕獲問題以及提高整體可讀性和可維護性的簡單快速的方法。

Observability  可觀察性

YES ?

中等規模的應用程序是觀察性開始變得至關重要，并可能節省大量時間和金錢的時候。通過在您的應用程序中設置觀察性，我們可以輕松監控、理解并排除系統性能和整體健康狀況的問題。

有多種工具和技術可用于在你的應用程序中構建可觀察性，例如日志記錄、度量收集和分布式追蹤。目標是快速識別并解決問題，保持應用程序的性能，并盡量減少停機時間。

Accessibility 無障礙性

YES ?

無障礙并不僅僅是一個選項，它更是一項責任！確保你的應用程序對所有用戶，包括那些有殘疾的用戶，都是可訪問的，這不僅是正確的做法，而且在某些國家，這也是法律要求。作為前端工程師，我們有責任創建無障礙的網站，并且我們應該將其作為我們工作流程的一部分，納入我們的完成定義中。

Design system 設計系統

NO ??

設計系統是一套可復用的組件、指南和設計原則的集合，用于在多個應用程序或平臺上設計一致的用戶界面。雖然對于擁有多個產品和團隊的大型組織來說，實施設計系統可能非常有益，但對于中等規模的應用程序來說，這可能是不必要的。

而不是投入時間和資源去創建一個全面的設計系統，你應該專注于根據你的需求配置現有的組件庫，并在你的應用程序中建立一套指南和可重復使用的組件，以保持一致性并提高開發者的效率。

總結

過度工程化是所有惡的根源。當涉及到中等規模的應用開發時，我們大多數人都有罪。有些工具和技術是至關重要的，而有些則不值得投入，但重要的是要設定并維持一種通用的編碼風格，利用自動化防止錯誤進入生產環節，并保持技術債務的低水平。