前些日子，再看了看一個自己曾經編寫過的項目的源碼。此前，由於處理核心的增加，實踐中發現的問題不斷地參入代碼，某些模塊的代碼已經相對混雜，一直想找時間重構但是苦於沒有時間。於是，由另一個同事重構後交至我手中。從大局上看代碼，確實做到了高度的解耦，也引入了設計模式的一些概念，代碼結構比較清晰。可是仔細跟蹤分析後才發現，和我重構的思路不太一樣，至少要比我想到的要多兩層，而且其中復雜數據結構的大量應用，導致我再看代碼確實比較費力，調試跟蹤往往要推進好幾層才可以進入主要的邏輯處理層。心中不禁產生了一個矛盾，是自己想得簡單了，還是同事過度設計了。帶著這個疑問把問題拋到了“知乎”。下面給大家看看幾條討論：
孫立偉，17歲開始玩電腦，並以此為生。十年軟件開…： 首先從語言層面來說，Java語言比C++語言封裝得更好，比較純粹的面向對象語法和一套標准的開發庫，大大簡化了開發的難度。而C++語言比較底層，再加上它需要對C保持兼容，導致使用C++語言做開發時，對以前使用C開發，剛剛轉入C++沒幾年的人，很難把思路從面向過程轉向面向對象上來，這是我在實際工作中常常看到的現象，例如頻繁的使用單例模式，習慣使用printf, sprintf，習慣使用FILE和宏，參數全部使用指針等等。不過，這裡無意引起一個老套的爭論，C++好還是Java好，或者面向對象好還是面向過程好。我個人的觀點是，任何一種計算機語言都有解決問題的能力，針對不同的項目，不同的問題域，甚至是針對個人習慣，采用哪種語言都行。說句極端的話，你要使用腳本如JavaScript, Python, Ruby來開發，只要你寫得好，也是可以的。區別可能只是在於具體到某個項目上值不值得，或者可不可行的問題。 其次，我們碼農做程序開發，有一個很大的誤區，認為某項特定的技術如設計模式、C++模版、多線程技術）能夠解決所有的問題。有一句話是這樣形容的，“手裡有一把錘子，看哪裡都有釘子”。尤其是剛剛學習到的知識，總是有一股沖動，一有機會就想去使用它。說實話，本人也是如此。但是，從軟件項目的角度來看，這種做法是十分有害的，這裡就不展開談了時間太晚了Zzzzzz....)。 想要對業務邏輯解耦，必須對代碼進行進一步的抽象，但是並不意味這抽象程度越高，代碼邏輯就會變得復雜，也不意味著代碼越來越難讀。代碼的復雜程度應該和業務邏輯的復雜程度有一個正比的關系。只有需求復雜度上去了，代碼才應該越來越復雜。為了抽象而抽象，為了解耦而解耦是沒有意義的。 總之一句話，代碼復雜，抽象程度高，並不意味著你的代碼就理所當然的難以理解，變得很難讀。關鍵還是在於設計功力和編碼功力。
陳碩，Linux C++程序員，muduo網絡庫作者，weibo.com/giantchen…： 《 樸實的C++設計 》http://www.iteye.com/topic/736269 《關於Java開發不明白的一些問題》“ 解耦不過是一個用來迷糊人的手段,是追求過度設計的人顯擺的工具 。只有真正的內聚,沒有絕對解耦,但凡你在某個地方切斷聯系,那麼你必然會在另一個地方重新產生聯系”http://www.iteye.com/topic/947017
白順龍，碼農，使用C C++ java工作： 多層封裝，采用 復雜 的數據結構，代碼更直觀，易理解-----自己容易理解，不等於別人容易理解，或者你再過一段時間看看，說這話的人基本都是思維沒有扭轉過來。習慣了局限於自己代碼習慣，可能看優雅的代碼都不習慣。引入設計模式）後雖然做到了高度的解耦，------設計模式不是為了解耦，解耦只是帶來的效果，關鍵是清晰的功能分割，容易擴展。但基本不變的東西，或者本來就是耦合的東西就不需要引入一些模式。 但是代碼邏輯復雜了，怎麼平衡好？-----我問你，加法復雜還是乘法復雜，微積分呢，人們有了加法為何還要發明乘法這樣復雜的東西? 從1加到N 你願意一個一個加起來得出結果，還是用(1+n)*n/2直接得出結果？ 不要把自己停留在小學生水平，覺得初高中的東西復雜，那樣你永遠只能做小學生的題。到了初中，乘法就是小孩子游戲，根本不需要特別注意什麼時候用乘法，到了大學生水平，知道什麼時候該用微積分，簡單的方程是再顯然不過的事情。該用什麼數學工具就用什麼數學工具。
余天升，看似工科生的文科生，計算機技術研究生 如果不能平衡，我認為可以犧牲易用性，邏輯復雜一些也不要緊，以代碼質量為先。有可能是你的設計模式選錯了，嘗試一下有沒有一起解決的好方法。
Edwin，C++程序員 “但是代碼邏輯復雜了”又不是什麼缺點，關鍵寫出可復用性強而質量高的代碼。 要說到平衡的話，項目進度會有一個壓力，會影響到代碼質量吧。不過從長遠看，質量高的代碼還是降低成本的。
鄭書清，系統架構師 設計模式，能否發揮價值，還要看整個團隊是否都能認同，並且掌握。代碼是寫給入看的，人不爽了，就會破壞結構，最終導致無法維護。 模式也是為了統一風格，關鍵還是看團隊是否能達成一致標准，提高代碼質量。
很精彩的討論，觀點也都有自己的道理，大家會怎樣平衡呢？
本文出自 “永遠的朋友” 博客，請務必保留此出處http://yaocoder.blog.51cto.com/2668309/793035
