作者認為，許多程序員不知道如何組織代碼，如何提高效率，如何提高代碼的可維護性、可重用性、可擴展性和靈活性。寫出來的代碼很亂，但是這麼多代碼可以正常運行。

你熟悉這段代碼經驗嗎？

周圍有很多程序員都會有這樣的經歷，過了一年左右再查一次就寫了代碼，驚訝地想，這麼糟糕的代碼，我以前寫過嗎？我能寫出這麼差的代碼！

對於仍然維護的代碼，重構的思想將被創建，或者將有更好的方法來實現它。這時，你和愛恨的代碼已經開始了……

本文主要從六個原則出發，作為設計模式的介紹，描述了六個基本原則與設計模式之間的關係。將遵循設計模式詳細介紹設計模式和日常開發。

基本規範和制約因素

對於基本的規範和約束，我相信每一個合格的團隊都會有一套自己的小工具。一方面要統一標準，提高可讀性和可維護性。另一方面，他們也會在離開辦公室後收到竊聽器。之後，他們也能更快地找到問題並解決問題。

實現了亂碼的大功能，對於後期的維護，無疑會迎接各種祖先。一個好的編碼習慣屬於一個合格的程序員的自我培養，他是人，沒有壞處。

關於開發中規範和約束的第一件事是命名。

這五年多的工作，合作和形形色色的人，記住，大多數時間，我已經對五個項目，業餘時間開發和維護同一時期，並有相互合作的英雄，相互學習，共同進步，在這個過程中，我認為最頭痛的問題未命名規範。

有許多非標準的風格，各種奇怪的名字都有。我見過這樣的一個名字，它有兩個功能，一個叫柱的細節，稱一列命名的消息，是“zhuanlaidetalactivity”和“zhuanlailiuyanactivity”，看到我的無知。

這樣的名字，你害怕害怕！這樣的名字都害怕，那是從未見過的世界，這至少可以看到，見過一些漢語拼音的縮寫，如動物檢疫證書命名那樣，這看起來更無知。

對於拼音命名，我不知道我是否會被解僱。我遇到了一些喜歡拼音命名的朋友。漢語拼音是中華民族弘揚漢文化的偉大創舉。但是編程的時候，拼音真的很低。

即使這項技術得到了年輕牛的支持，編寫的代碼也和學生的作品一樣。

另一件要強調的是註釋。許多人可能認為註釋越多，他們看到的就越好。

上次複查發現，當我的一些同事複製了一些代碼，其實是想做另一個功能，只是想把一些代碼複製並修改過去（我不喜歡重新創建，對於某些功能，最好做的稍微靈活一點，提高代碼的重用性和靈活性）。

事實上，一些可以重用的地方，不明白你為什麼不寫幾行代碼，這是不是一個東西，讓我很無知的力量是他們把我的筆記和過去的副本，當我走進課堂，我發現作者是飯桶，查看提交歷史上，沒有什麼是我的事，但這是完全不相干的功能描述......

對於註釋，還有一些冗餘註釋。這稱為良好的命名規範，結合了需要和命名。它可以省去許多不必要的註釋，如登錄、註冊、登錄和註冊註釋，這是完全不必要的。

良好的習慣可以給我們的發展帶來了很多便利，但有些人喜歡textview1，textview2命名，甚至添加註釋。當我用了以後，我看到一群羊駝跑，上下。

對於這樣的代碼，很多人會覺得正常。有些人會責怪老師對譚浩強的責任。是的，Tan Lao的書中有很多問題，但這不是編寫這種代碼的原因。

每天的開發，以及其他人平時的維護代碼，總是去調試for語句，不要認為這個代碼不好，看起來有點傻？即使是註釋，它仍然是一個整體。

因為每個團隊都有自己的規範和約束，公司會有自己的規範，統一在每一個團隊中，不同的語言有不同的約束，如果一天一天地的，會從博客寫一個詳細的限制和標準化。

為此，要寫的東西還真不少，比如在這混亂的情況下，1, 2, 3總是令人費解的，如必要的恆定的替代變量，如不是線程的線程池，如必要時使用的一個案例，真的很多事情，再也沒有比下面的走到今天第一個焦點，命名和註釋。

建議：合理使用筆記，對於新手在學習期間，在新的代碼和不清楚的邏輯上，儘量多記筆記，便於理解，對於老兵來說，儘量做到標準命名。

通過命名來實現註釋的效果，必要的註釋對於降低複雜的維護成本仍然很重要。

一些應該廣為人知的編程思想

一個程序員花費大約10-12的工作時間來編寫程序。大多數程序員每天可以寫十幾行代碼，它們可以進入最終產品，不管他們的技術水平有多高，10-20%。

優秀的程序員花了90%的時間思考、研究和實驗，以找出最佳答案。可憐的程序員花了90%的時間調試問題程序，盲目修改程序，希望某種形式的寫作是可行的。

對於一個好的程序員來說，邏輯是最重要的。他們願意花更多的時間思考。同時，會出現更少的錯誤，甚至錯誤率可以降低到非常低的水平。

我並不是很優秀的開發者，但這些年依然有這麼一個習慣，對於複雜或者多樣的功能，總會先理清思路，先列舉出會有哪些操作，哪些地方是 Bug 的雷區應該多注意，我也經常會和隊友提起，一圖勝千言，理清思路再下手，事半功倍。

不管業務邏輯是否複雜，它都是乾的，那麼找出修改錯了找不到添加，這就導致一塊代碼總是堆在哪裡，經過幾次修改，已經發生了巨大的變化，對於維護的人來說，這是不值得的。

對此，筆者也建議讀者、朋友先嚐試一下，先動手動手，再把一個模塊分解成一個接口，通過接口實現模塊，做界面編程，這樣可維護性會大大提高。

對於模塊間的通信，不應該是類間的關聯，而是通過抽象來實現交互，抽象不應該依賴於細節，細節應該依賴於抽象，它是非常費解的，說白了，就是面向接口的編程，而不是實現。

這樣做的好處就是，將來你要把這個被調用的類換成一個別的實現類時，你就不用去把調用過它的類一個個改掉了，因為它們調的是接口，接口沒變，在配置裡把接口的實現類換成新的類，就全部都替換掉了。

類之間的耦合越弱，重用的好處就越大，而弱耦合類被修改，不會引起相關類的波紋。

建議：理順思路，提高成績兩倍。在開發過程中，我們還可以定義一個良好的接口，通過接口的實現來完成模塊的開發，儘可能地減少錯誤率，編寫更高質量的代碼。

技術能力的改進主要體現在代碼的“高內聚、低耦合”，因為這些想法導致許多發展模式，如流行的MVC、MVP，MVVM等。

版本迭代與重構

當我們不期望任何系統，確定系統要求的時候，就永遠不會改變，這是不現實的，也不是科學的想法，而且既然需求會改變，如何面對需求的變化，設計軟件可以相對容易地修改，從而不說新的需求方式，放下整個程序。

相信我的很多朋友都曾經遇到過，原本很普通的需求，經歷了N次迭代和修改，已經形成了巨大的功能，隨著不斷迭代版的維護成本越來越高，從而形成惡性循環，這段代碼正處於歷史重構的階段。

不可否認的是，從維護成本的角度來看，重構確實是一個很好的解決方案。改造成本比原基地維修費用小，便於日後維護。一些公司甚至在多次迭代後推動整個項目重建，這不僅發生在小公司，而且也發生在大公司中。

從技術上講，有三件事要做一個複雜的代碼重構舊代碼時：理解，分解舊代碼，代碼和勾建信。

重建舊的代碼往往是很難理解的，尤其是在迭代和多處理模塊；鉛超標QianYiFaErDongQuanShen模塊之間的耦合，難以控制的影響範圍；舊的代碼是不容易測試確保新代碼的正確性，尤其是當產品文檔不完整。

這是最後一篇評論中發現的一段代碼。這不是標準規格。這是重複產品迭代後的結果，但這不是藉口。必須建造這麼多輪子。作為反編譯教材的可重用性的代碼，它是淋漓盡致的，如果有更多的狀態，它會重複多次在這裡。

建議：重構不是一個通用的重構代碼。當後續版本的經驗再次被修改時，代碼是混亂的。塊的代碼總是重複。

既然無法確定需求會發生變化，那麼我們只能提高代碼處理的現狀，合理設計界面，每次變化都需要更多的思考，對於重複使用的代碼進行包提取，儘可能少地改變已有的邏輯。

設計模式的重要性

建築工程師是不造磚的建築工程師。

以前說過很多話。現在我們來直接討論設計模式的重要性。談到設計模式，我們必須提到六個基本原則和體系結構設計，並提到建築設計和設計模式的重要性。

首先，六項基本原則仍然有些爭議。書我之前看到的通常是單一職責原則、德米特里法則、lehis替換原則，開閉原則，依賴倒置原則、接口隔離原則。

但我在最近的一些帖子中看到，有一種說法，即沒有接口隔離的原則，但這是合成/聚合的原則。為了不影響以前的準備，合成/再利用的原則被挑選出來。

六項基本原則是整個建築設計的靈魂和建築設計的指導思想。設計模式是建築設計的一種具體設計手法，是建築設計的具體實踐。

從建築設計的角度看，建築設計主要體現在抽象能力上。抽象能力依賴於建築編碼的經驗、功能的分解和理解、邏輯的嚴密性。

做架構設計應該儘可能且更全面的考慮問題，儘可能做好代碼的包容性，海納百川，有容乃大之勢，這是架構設計者應該具備的基本條件。

越體貼，越包容，越困難，對自己的障礙就越大。我們應該抽象這些細節並提出解決方案。抽象級別越高，解決方案越合理。這就是建築師的價值。

從具體要求到代碼實施，再到具體產品。體系結構設計的目的無非是系統的可重用性、可擴展性和穩定性。具體事物不能很好地反映這些特徵，只有抽象的事物才能最好地反映。

在建築設計過程中，單一職責原則告訴我們，我們應該更好地反映高內聚、低耦合，這個類是用來請求數據，不要把JSON解析方法，如果類是用於加載圖片，查看筆記，請分開，做了一個類只有一個責任，原因只有一個改變。

如果一個類的責任越多，這些責任的耦合就會帶來一些不必要的維護成本。從大的角度來看，MVP和MVC模式都是單責原則、模型-視圖-控制隔離和職責的體現。

德米特里定律告訴我們，如果兩個類不需要直接進行交流，那麼這兩個類就不應該有直接的交互。如果其中一個類需要調用其他類中的一個，則調用可以由第三個類轉發。

類之間的耦合越弱，重用的好處就越大，而弱耦合類則被修改，從而不影響相關類。重點在於類之間的鬆散耦合。

許多人都沒有聽說過這個詞的替代李的原則，但他們總是在實際開發過程中使用它。事實上，很簡單，子類型必須能夠替換其父類型。

例如，“列表 =新列表（ArrayList <>）；“這樣做的好處其實很簡單，比如，一天中不能滿足需求，需要使用LinkedList，只需要用鏈表代替ArrayList，而不是全局列表又變了似的，提高可維護性。

開合原理是面向對象原理的核心，它由開放性擴展和修改封閉兩部分組成。軟件需求總是變化。對於軟件設計者來說，在不改變原有系統的前提下，實現靈活的系統擴展是非常必要的。

擴展和開放是抽象編程，而不是特定的編程，因為抽象是相對穩定的，邊界擴展受接口或抽象類擴展的限制，公共方法不允許出現在接口或抽象類中。

讓類依賴於一個固定的抽象，因此修改是關閉的。這是基於繼承和多態性的，可以從抽象類繼承，並通過覆蓋其方法來擴展方法。

依賴倒置原則是基於抽象的，而不是基於具體實現的。如上所述，它實際上是面向接口編程而不是實現編程。這樣做的好處是耦合。

一般來說，抽象更改的概率非常小，使得用戶程序依賴於抽象，而且實現的細節也依賴於抽象。即使實現細節在不斷變化，只要抽象不改變，客戶機程序也無需更改。這大大減少了客戶機程序和實現細節之間的耦合。

接口隔離的原則是“使用多個專門接口比使用單個接口要好”。

一個模塊應該依靠它提供的接口，接口是採用什麼樣的接口所需要的下降，同時也應遵循單一責任原則，從而避免了臃腫的接口汙染，界面不會合並關係結合起來，形成一個大的臃腫的接口，是一種對接口汙染。

接口的粒度也不能太小，太小會導致接口額數量劇增，對開發人員不友好；接口額粒度太大，靈活性降低，無法提供定製服務，給整體項目帶來無法預估的風險，合理的設計接口，也是一門藝術。

這張照片肯定有很多爭議，因為許多設計模式都使用了許多基本原理，上面是對設計模式的粗略總結。

在六項基本原則（包括合成/聚合複用原則）體現在設計模式，同時也說明了六項基本原則和23種設計模式是互補的，六個基本原則和模板設計模式的基礎上，設計模式是靈活運用的六個基本原則的體現。

關於合成/聚合再利用的原理有一些爭議。在某些書籍中，保留了合成/聚合的原則，去掉了接口隔離的原則。組合/聚合的原則是使用較少的繼承和綜合關係。

合成和聚合是一種對象建模協會，一個弱的聚合關係表示，整體由部分構成，部分可以脫離整體的存在作為一個獨立的個體，合成是一種強制，體現了部分與整體之間的嚴格關係，一致的部分和整個生命週期的一部分，不能脫離整體。

總結

六個基本原則是面向對象思想的體現。單任務原理和接口隔離原則體現了封裝的思想。開合原則體現了對象的封裝性和多態性，而置換原則則是對象繼承的規範。

關於倒置的原則，它是多態性和抽象思維的體現。在充分理解面向對象的基礎上，掌握基本的設計原則，靈活地應用於項目設計，可以提高代碼質量和結構設計。

特別是，它可以保證可重用性、可維護性、可擴展性和靈活性，這也是理解和掌握設計模式的基本知識。

補充

對於六項基本原則，我們的發展要熟悉頭腦，靈活運用。為了使設計模式在日常的發展中得到應用，我們必須強調最好的方法是適合自己。

如果一個模塊是非常輕量級的，並且只有使用設計模式才能使用設計模式，這無疑會使項目變得不倫不類，臃腫，還帶來一些不必要的維護成本（雖然維護成本非常低）。