Course Module 3 a ɛto so abien - Lecture: 反模式

反模式簡介

反模式與模式完全相反。回想一下，設計模式是良好編程實踐的示例，即用於解決某些問題的模式。但反模式是它們的完全對立面，即在解決各種問題時所犯錯誤的模式。

良好編程實踐的一部分恰恰是避免反模式。不要認為這是一個難以理解的理論垃圾——這些是幾乎每個開發人員都遇到過的具體問題。誰知道，他有武器！

讓我們看一下初學者中常見的一些反模式：

幻數是代碼中用於某些事物（通常是數據標識）的常量，如果沒有相應的註釋，其數字本身沒有任何意義。數字絕對沒有語義。

當數字開始出現在你的項目代碼中時，其含義並不明顯，這是非常糟糕的。不是此類代碼作者的程序員將難以解釋其工作原理。久而久之，連魔數代碼的作者都解釋不清了。

數字使代碼難以理解和重構。造成這個錯誤的主要原因是開發倉促，缺乏編程實踐。通過在開始開發之前規定數字常量的使用，應該將這種反模式消滅在萌芽狀態。

要解決這個問題，您需要創建一個變量，其名稱解釋數字常量的用途，並為其分配所需的值。

divine object是一種反模式，在 OOP 開發人員中很常見。這樣的對象承擔了太多的功能和/或存儲了幾乎所有的數據。結果，我們有一個不可移植的代碼，而且很難理解。

此外，這樣的代碼很難維護，因為整個系統幾乎完全依賴於它。出現此錯誤的原因：開發人員能力不足，一個開發人員承擔了大部分工作（尤其是當工作量超過該開發人員的經驗水平時）。

有必要通過將任務分解為不同開發人員可以處理的子任務來處理這種方法。

過早的優化是在程序員獲得關於在哪里以及如何做的明智決定所需的所有信息之前執行的優化。

實際上，很難預測哪裡會出現瓶頸。在獲得實證結果之前嘗試優化會導致代碼複雜和錯誤的出現，但不會帶來任何好處。

如何避免？首先，使用眾所周知且經過驗證的算法和工具編寫乾淨、可讀、有效的代碼。如有必要，使用分析工具查找瓶頸。依靠測量，而不是猜測和假設。

在分析之前緩存。使用複雜且未經證實的啟發式方法而不是數學上正確的算法。精選的新的、未經測試的框架可能在負載下表現不佳。

確定優化何時為時尚早並不容易。提前預留成長空間很重要。您需要選擇能夠輕鬆優化和發展的解決方案和平台。有時過早的優化也被用作錯誤代碼的藉口。例如，他們採用 O(n2) 算法只是因為該算法會更難 O(n)。

這種反模式的意思是程序員開發自己的解決方案來解決已經存在的問題，而且通常是更成功的解決方案。

開發人員認為自己更聰明，因此他嘗試為每項任務提出自己的解決方案，儘管他的前輩有經驗。大多數情況下，這只會導致時間的浪費和程序員效率的降低。畢竟，即使找到解決方案，也可能不是最佳解決方案。

當然，你不能完全放棄獨立解決方案的可能性，因為這會導致直接複製粘貼編程。開發人員必須導航可能出現在他面前的任務，以便勝任地解決它們，使用現成的解決方案或發明自己的解決方案。

很多時候，出現這種反模式的原因很簡單，就是沒時間。時間就是金錢。

這種反模式與簡單地重新發明輪子密切相關——當存在更好的解決方案時創建你自己的糟糕解決方案。

這種反模式花費了兩倍的時間：首先，時間花在發明和實施你自己的解決方案上，然後是重構或替換它。

程序員必須了解針對特定任務範圍的各種解決方案的存在，並以它們的優缺點為指導。

作為程序員，你將面臨的所有問題都可以分為兩部分：

大多數編程問題在您出生之前就已成功解決。無需發明任何東西 - 只需研究其他人的經驗（這就是寫書的目的）。

2022年，我們可以慶祝以下生日：

編程語言
- C 語言 50 週年（1972 年）
- Java 語言 27 週年（1995 年）
- Python 31 歲生日 (1991)
聯繫
- 互聯網 39 週年 (1983)
- 手機滿49歲（1973年）
- 30 年前（1992 年）發送了第一條短信
圖案
- MVC 模式誕生 44 週年（1978 年）
- SQL 發明於 48 年前（1974 年）
- 26 年前（1996 年）發明了 Java Beans
圖書館
- Hibernate 發明於 21 年前（2001 年）
- Spring 是 20 年前發明的（2002 年）
- 23 年前發布的 Tomcat（1999 年）
操作系統
- Unix 發布 51 年前（1971 年）
- Windows 誕生於 37 年前（1985 年）
- 21 年前（2001 年）發布的 Mac OS

所有這些東西不僅僅是發明出來的，它們是作為解決當時非常普遍和相關問題的解決方案而開發的。