可觀察性驅動開發與測試驅動開發
可觀察性的概念涉及通過檢查日志、指標和跟蹤來了解系統的內部狀態。這種方法提供了一個全面的系統視圖，允許進行徹底的調查和分析。
雖然將可觀察性整合到系統中似乎令人望而生畏，但好處是巨大的。一個著名的例子是 PhonePe，通過實施數據可觀察性解決方案，它的數據基礎架構增長了 2000%，數據管理成本降低了 65%。這有助于緩解性能問題并最大限度地減少停機時間。
可觀察性驅動開發 (ODD) 的影響不僅限于 PhonePe。許多組織都體驗到了 ODD 的好處，發現問題的可能性提高了 2.1 倍，解決問題的平均時間縮短了 69%。
什么是ODD?
可觀察性驅動開發 (ODD) 是一種將左可觀察性轉移到軟件開發生命周期最早階段的方法。它使用基于跟蹤的測試作為開發過程的核心部分。
在 ODD 中，開發人員在編寫代碼的同時聲明您查看系統內部狀態和過程所需的輸出和規范。它適用于組件級別和整個系統。ODD 也是一種標準化儀器的功能。可以跨編程語言、框架、SDK、API。
什么是 TDD?
測試驅動開發 (TDD) 是一種廣泛采用的軟件開發方法，強調在編碼之前編寫自動化測試。TDD 的過程包括通過創建測試用例來定義軟件的預期行為，運行測試以確認其失敗，編寫最少的必要代碼使測試通過，并通過重構改進代碼。針對每個新功能或需求重復此循環，由此產生的測試可作為防止未來潛在回歸的保障。
TDD 背后的哲學是編寫測試迫使開發人員考慮手頭的問題并生成重點突出、結構良好的代碼。遵守TDD可以提高軟件質量和需求合規性，并有助于及早發現和糾正錯誤。TDD被認為是提高軟件系統質量、可靠性和可維護性的有效方法。
可觀察性和測試驅動開發的比較
相似之處
可觀察性驅動開發 (ODD) 和測試驅動開發 (TDD) 致力于提高軟件系統的質量和可靠性。這兩種方法都旨在確保軟件按預期運行，最大限度地減少停機時間和用戶面臨的問題，同時促進對持續改進和監控的承諾。
差異
- 重點： ODD 的重點是實時持續監控軟件系統及其組件的行為，以識別潛在問題并了解系統在不同條件下的行為。另一方面，TDD 會在錯誤對系統或用戶造成損害之前優先檢測和糾正錯誤，并驗證軟件功能是否滿足要求。
- 時間和資源分配：實施 ODD 需要投入大量時間和資源來設置監控和日志記錄工具和基礎設施。相比之下，TDD 需要在開發階段投入大量時間和資源來編寫和執行測試。
- 對軟件質量的影響： ODD 可以通過提供對系統行為的實時可見性來顯著影響軟件質量，使團隊能夠在問題升級之前檢測并解決問題。TDD 還有可能通過在錯誤進入生產環境之前檢測和修復錯誤來顯著影響軟件質量。但是，如果測試不全面，錯誤仍可能逃避檢測，從而可能影響軟件質量。
在生產中從 TDD 轉向 ODD
在軟件開發中從測試驅動開發 (TDD) 方法轉變為可觀察性驅動開發 (ODD) 方法是一個重大變化。多年來，TDD 一直是在將軟件發布到生產環境之前對其進行測試的既定方法。
雖然 TDD 通過重復測試提供一致性和準確性，但它無法深入了解整個應用程序的性能或真實場景中的客戶體驗。通過 TDD 進行的測試是孤立的，不能保證實時應用程序中沒有錯誤。此外，TDD 依賴于一致的生產環境來進行自動化測試，這并不代表真實場景。
另一方面，可觀察性是 TDD 的進化版本，它提供對基礎設施、應用程序和生產環境的全棧可見性。它通過日志、跟蹤和指標等遙測數據確定影響用戶體驗和產品發布的問題的根本原因。這種持續監控和跟蹤有助于預測最終用戶對應用程序的看法。
此外，有了可觀察性，就可以在代碼到達源代碼控制之前編寫和發布更好的代碼，因為它是工具、流程和文化集的一部分。
實施 ODD 的最佳實踐
以下是實施可觀察性驅動開發 (ODD) 的一些最佳實踐：
- 從一開始就優先考慮可觀察性：從一開始就在開發過程中考慮可觀察性。這將幫助您及早發現潛在問題并實時進行必要的更改。
- 采用端到端方法：確保可觀察性涵蓋系統的所有方面，包括基礎設施、應用程序和最終用戶體驗。
- 監控和記錄一切：從所有來源收集數據，包括日志、跟蹤和指標，以全面了解系統的行為。
- 使用自動化工具：利用自動化的可觀察性工具實時監控系統并提醒您任何異常情況。
- 與其他團隊協作：與DevOps、QA 和生產等團隊協作，以確保將可觀察性集成到開發過程中。
- 持續監控和改進：定期監控系統，分析數據，并根據需要進行改進以確保最佳性能。
- 擁抱持續改進的文化：鼓勵開發團隊擁抱持續改進的文化，并持續監控和改進系統。
結論
可觀察性驅動開發(ODD)和測試驅動開發(TDD)都在確保軟件系統的質量和可靠性方面發揮著重要作用。TDD 側重于在 bug 損害系統或其用戶之前檢測并修復它們，而 ODD 側重于實時監控軟件系統的行為以識別潛在問題并了解其在不同場景下的行為。
