前些日子，再看了看一个自己曾经编写过的项目的源码。此前，由于处理核心的增加，实践中发现的问题不断地参入代码，某些模块的代码已经相对混杂，一直想找时间重构但是苦于没有时间。于是，由另一个同事重构后交至我手中。从大局上看代码，确实做到了高度的解耦，也引入了设计模式的一些概念，代码结构比较清晰。可是仔细跟踪分析后才发现，和我重构的思路不太一样，至少要比我想到的要多两层，而且其中复杂数据结构的大量应用，导致我再看代码确实比较费力，调试跟踪往往要推进好几层才可以进入主要的逻辑处理层。心中不禁产生了一个矛盾，是自己想得简单了，还是同事过度设计了。带着这个疑问把问题抛到了“知乎”。下面给大家看看几条讨论：
孙立伟，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++程序员
“但是代码逻辑复杂了”又不是什么缺点，关键写出可复用性强而质量高的代码。
要说到平衡的话，项目进度会有一个压力，会影响到代码质量吧。不过从长远看，质量高的代码还是降低成本的。
郑书清，系统架构师
设计模式，能否发挥价值，还要看整个团队是否都能认同，并且掌握。
代码是写给入看的，人不爽了，就会破坏结构，最终导致无法维护。
模式也是为了统一风格，关键还是看团队是否能达成一致标准，提高代码质量。
很精彩的讨论，观点也都有自己的道理，大家会怎样平衡呢？
本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/793035如需转载请自行联系原作者
yaocoder
