聲明：本篇文章包含聯盟鏈接；如果您透過本文中的不同鏈接購買產品或服務，我可能會獲得補償。
image_credit - ByteByteGo
朋友們好，軟體設計和系統設計是開發過程中的關鍵面向，能顯著影響專案的成功與維護性。
雖然精通軟體設計需要時間與經驗，但開發人員可以迅速學習幾個關鍵的最佳實務來提升程式碼品質。
之前我解釋了像是 API Gateway 與負載均衡器的差異、正向代理與反向代理 等關鍵系統設計概念，以及一些常見的 系統設計問題，用於系統設計面試，但在本篇文章中我將討論最佳實務。
您將學到在編寫程式時可以使用的程式碼最佳實務、創建程式時的程式設計最佳實務以及設計軟體時可以考慮的更高層級的軟體設計實踐。
順便提一下，如果您正在準備系統設計面試並想深入了解系統設計，您還可以查看像是 ByteByteGo、Design Guru、Exponent、Educative、Codemia.io 和 Udemy 等網站，它們提供了許多優秀的系統設計課程。
此外，了解各種架構模式，如對等模式和API Gateway，對於設計能夠承受生產考驗的系統也大有裨益。話說這裡有一幅來自 DesignGuru.io 的微服務架構圖：
注意：請閱讀到最後，我有一個獎勵給你。
10 個學習的系統設計 + 程式碼 + 程式設計最佳實務
在這篇文章中，我們將探索 10 個可以在 10 分鐘內掌握的重要軟體設計最佳實務。
1. 模組化
模組化是將複雜系統拆分成小型、可管理和獨立模組的過程。
當不遵循模組化時，程式碼變得複雜，維護困難，並缺乏適應變更的靈活性。
擁抱模組化能使代碼更有組織性、可重用性和可擴展性，從而使開發和維護變得更高效。
以下是實現項目模組化的幾個建議：
- 將程式碼劃分為小型獨立模組。
- 每個模組應有明確的責任或功能。
- 促進可重用性和可維護性。
範例： 假設有一個銀行應用程序。與其有一個處理所有方面（例如帳戶管理、交易、身份驗證）的整體程式碼，倒不如將其拆分為像 AccountManager、TransactionProcessor 和 AuthenticationService 這樣的模組。每個模組負責特定功能，促進代碼的組織和重用。
2. 封裝
封裝是物件導向程式設計中的基本概念，它涉及將操作數據（屬性）和方法（函數）封裝在單個單元中，即類。
其核心思想是封裝或屏蔽物件的內部細節，允許對物件功能的控制訪問。
物件的內部狀態通常受到限制，與物件的交互是通過明確定義的接口進行的。
封裝透過限制對物件內部狀態的直接訪問，促進了更安全、可維護和可理解的代碼庫。遵循封裝原則會導致更易於管理、更新和調試的代碼。
未能進行封裝可能導致不可預期的行為、依賴性增加，以及維護和進化軟體的困難。
以下是實現更好封裝的方法
- 封裝模組的內部細節，只暴露必要的部分。
- 使用訪問修飾符來控制可見性（例如，public、private、protected）。
- 減少依賴性並隔離變更。
範例
假設有一個名為 BankAccount 的類。若沒有封裝，所有屬性（例如，餘額、帳戶號碼）和方法（例如，存款、提款）可能都是公有的，使外部代碼能直接操作這些變數。
然而，通過封裝，這些屬性變成私有，並提供方法來與之互動。例如，withdraw方法在更新餘額之前會進行必要的驗證。
這種封裝確保BankAccount物件的內部狀態受到保護，並且通過控制方法進行交互。
3. 一致的命名規範
一致的命名規範是一組指南，用於命名變數、函數、類和其他程式碼實體，確保其統一和標準化。
在程式碼庫中採用一致的命名約定可以提高可讀性、可維護性及開發者之間的合作。
這些約定確定了表達各代碼實體的目的和角色的共通語言，使得開發者更易於理解和操作程式碼。
範例：
考慮到一種情況，您有一個類表示電商應用中的客戶。若具備一致的命名約定，與客戶有關的屬性和方法可能遵循類似 customerId、 customerName和 getCustomerDetails()的模式。
若沒有一致的命名規範，您可能會遇到像custID、cust_Name和fetchDetailsForClient()這樣的變化。前者提供了一種清晰且標準化的方法，而後者可能導致混淆並增加開發者的認知負擔。
以下是實現一致命名的幾個建議：
- 採納一致的命名約定用於變數、函數及類。
- 增強程式碼可讀性，使他人更容易理解您的程式碼。
- 遵循您所使用的編程語言或框架的既定命名慣例。
簡而言之，一致的命名規範對於創建可維護、可讀及合作的程式碼至關重要。
通過確定和遵守一套標準的名稱規則，開發團隊能夠促進對代碼庫的共同理解，簡化合作並提高整體軟體質量。
4. SOLID 原則
SOLID 是一個縮寫，代表一組在物件導向程式設計中的五條設計原則，旨在創建更可維護、可擴展和靈活的軟體。
這些原則由 Robert C. Martin 在他經典著作 Clean Code 中提出，被視為構建健壯、物件導向系統的基礎。
以下是實現 SOLID 原則的幾個建議：
- 學習並應用 SOLID 原則（單一責任、開放/關閉、里氏替代、介面隔離、依賴反轉）。
- 有助於創建更可擴展、靈活和可維護的軟體。
遵循SOLID 原則能促進高品質、可維護和可擴展的軟體的創建。
這些原則為設計靈活和模組化的系統提供了指導，能隨著需求的變化而演變，並且更易於理解和擴展。
5. DRY（不要重複自己）
DRY，即不要重複自己，是一個軟體開發原則，鼓勵消除程式碼重複。
其核心思想是通過確保某個知識（程式碼、邏輯或功能）僅在程式碼庫中的一個地方表達，來促進程式碼的可重用性和可維護性。
DRY 旨在減少冗餘性，提高一致性，並使程式碼庫更高效。
範例：
假設您有一個網路應用程式，在多個地方需要驗證用戶資訊——例如在用戶註冊、登錄及個人資料更新期間。
若不遵循 DRY，您可能在每個場景中重複相似的驗證邏輯。
然而，通過應用 DRY，您可以創建一個集中驗證模組或函數，在所有這些環境中重用。
這樣，對驗證規則的任何變更或更新都可以在一個地方進行，確保一致性並最小化由於不一致規則導致的錯誤可能性。
以下是實現 DRY 的幾個建議：
- 避免重複程式碼；而是創建可重用的函數或類。
- 減少錯誤風險，使程式碼更易維護。
總結來說，DRY 是一個促進程式碼效率、一致性和可維護性的基本原則。
通過消除冗餘並集中知識，開發人員創建更易於閱讀、更新和擴展的程式碼，最終導致更健壯和可持續的軟體。
6. 關注點分離
關注點分離（Separation of Concerns, SoC）是軟體設計原則，主張將計算機程式劃分為區分且獨立的部分，每個部分處理特定的關注或功能面向。
其目標是隔離不同的責任，確保每個組件專注於單一任務，使系統更具模組性、可維護性和可理解性。
範例：
**考慮一個同時處理用戶身份驗證和從資料庫中檢索數據的網路應用程式。
若不執行關注點分離，處理身份驗證的程式碼和處理資料庫查詢的程式碼可能密切交織在一起。**
然而，通過應用 SoC，這些關注被分離為不同的模組。身份驗證模組處理用戶身份驗證邏輯，而數據檢索模組則管理與資料庫的交互。
這種分離使得維護更容易，因為對一個關注的變更不會影響到另一個。
以下是實現更好的關注點分離的方法：
- 將程式碼劃分為不同的部分，每部分處理特定的關注。
- 改善程式碼組織，使其更易於理解和維護。
總之，關注點分離是有助於軟體清晰度、可維護性和可擴展性的基本原則。
通過將不同的關注隔離到不同的模組或組件中，開發人員能夠創建更易於理解、修改和擴展的系統，從而導致更健壯和適應力強的軟體架構。
7. 錯誤處理
錯誤處理是軟體開發中的一個重要方面，涉及管理和應對程式執行期間的意外情況或錯誤。
適當的錯誤處理確保應用程序能夠優雅地處理異常，為用戶提供有意義的反饋，並防止災難性故障。
有效的錯誤處理包括預測潛在問題、識別錯誤點，並實施管理和恢復錯誤的策略。
範例：
想像一個與資料庫互動以檢索用戶資訊的網路應用程式。如果沒有適當的錯誤處理，當資料庫連接失敗或查詢出現問題時，應用程式可能會崩潰，或向用戶顯示不明的錯誤信息。
然而，若有健全的錯誤處理，應用程式可以捕獲這些異常，記錄錯誤詳細信息以進行除錯，並顯示用戶友好的消息，提示用戶資料庫連接有問題。
以下是實現更好錯誤處理的幾個建議：
- 實施適當的錯誤處理機制，以優雅地處理意外情況。
- 使用try-catch區塊或類似的結構來管理異常。
總之，錯誤處理是軟體開發的基本方面，增強了應用程式的韌性、可用性和安全性。
忽視適當的錯誤處理可能導致用戶體驗不佳、安全漏洞以及診斷和解決問題的困難。一個健全的錯誤處理策略是創建可靠且用戶友好軟體的必需條件。
8. 註解與文檔
註解和文檔是軟體開發中的關鍵元素，能提高程式碼的理解力、可維護性和合作性。
註解是程式碼內部的注釋，提供附加信息、解釋或背景，而文檔則是對程式碼目的、結構和用法的外部描述。
兩者共同有助於為開發者、維護者和其他相關人員創建全面的軟體理解。
範例：
考慮一個涉及特定排序邏輯的複雜算法。如果沒有註解和文檔，其他開發者可能難以理解程式碼。
在這種情況下，您可以在程式碼中使用註解解釋每個步驟的目的、背後的理由或任何潛在的邊界情況。
此外，您還可以提供外部文檔，概述如何使用排序算法、其時間複雜度和任何性能考量。
以下是實現更好文檔的幾個建議：
- 添加有意義的註解，以解釋程式碼中複雜的部分。
- 為您的程式碼庫撰寫清晰簡潔的文檔。
- 有助於他人理解您的程式碼，加速入職。
總之，註解和文檔在確保程式碼庫的可維護性、可讀性和合作性中起著至關重要的作用。
雖然寫得好的程式碼是必要的，但補充註解和文檔則為開發者和相關人士創建了更全面且易於訪問的資源。
9. 測試驅動開發（TDD）
測試驅動開發（TDD）是一種軟體開發方法，編寫測試在實際程式碼實現之前進行。
TDD 循環通常包括三個步驟：編寫失敗的測試、編寫使測試通過所需的最少程式碼，然後在確保測試仍然通過的情況下重構程式碼。
TDD 強調通過對軟體單元進行持續和自動化測試，創建可靠且可維護的程式碼。
範例：
假設您被指派開發一個計算給定數字階乘的函數。在 TDD 中，您將首先編寫一個測試，該測試指定該函數的預期行為。**
最初的測試可能會驗證 5 的階乘等於 120。這個測試一開始會因為您尚未實現階乘函數而失敗。
接下來，您將編寫使測試通過所需的最少程式碼。 在這種情況下，您將實現階乘函數，以正確計算給定數字的階乘。
一旦測試通過，您可能會針對邊界情況（如 0 或 1 的階乘）編寫額外的測試，然後重複該循環。
以下是遵循測試驅動開發的幾個建議：
- 在編寫實際程式碼之前編寫測試。
- 確保程式碼符合指定要求，並更易於重構。
總結來說，測試驅動開發是一種推動軟體開發的嚴格系統方法。
通過先編寫測試，開發人員為程式碼建立了一個安全網，從而提高了可靠性、可維護性和對軟體正確性的信心。
10. 性能考量
性能考量在軟體設計中至關重要，以確保應用程式高效運作且滿足用戶期望。
通過在演算法選擇、資料結構設計和資源管理中做出明智的選擇，開發人員可以創建在苛刻條件下也能良好運行的軟體。
優化工作能夠帶來更快的響應時間、提高可擴展性和全面增強用戶體驗。
以下是提高軟體性能的幾個建議：
- 在設計軟體時注意性能影響。
- 選擇適當的資料結構和演算法。
- 定期剖析和優化程式碼中的關鍵部分。
結論：
這就是所有內容。在短短 10 分鐘內，開發人員可以熟悉這些基本的軟體設計最佳實務。
雖然軟體設計是一個廣泛且不斷發展的領域，但採納這些實務會為編寫乾淨、可維護及可擴展的程式碼打下基礎。
隨著開發人員獲得更多經驗，還可以深入研究更高級的設計概念，但掌握這些基礎對構建健壯且高效的軟體解決方案至關重要。
獎勵
如承諾，這裡有個獎勵——一本免費書籍。我剛找到一本學習分散式系統設計的新免費書籍，您也可以在微軟的這裡查看——https://info.microsoft.com/rs/157-GQE-382/images/EN-CNTNT-eBook-DesigningDistributedSystems.pdf
原文出處：https://dev.to/somadevtoo/10-software-design-and-programming-best-practices-for-developers-ecn
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式