我曾经去给OSCHINA做过一期有关“软件工程实践”的有奖高手问答 （奖是给提问者的，哈哈），现在来看，许多问题仍然可读之处，因此整理成文字，以为众赏。
原贴在这里：http://www.oschina.net/question/12_78459
本篇的问题有两个：架构是否就是把问题域理清楚？软件工程各要素可有比重？
问：
一、关于架构。
我认为架构就是把问题域的方方面面理清楚咯，设计出尽可能简单的解决方案。这里的核心问题是，把复杂的变得简单,而不是把简单问题或者比较复杂的问题变得更加复杂。这里的简单包括理解起来简单，扩展起来简单，和团队沟通起来简单等。而把复杂问题变得简单的这个能力就是所谓的“架构师的素质、思维”，这里自然就有个级别的问题在里面，对问题域能驾驭的复杂度越高，“架构的能力”就越强，觉得这样理解对不对？或者你有更好的补充？
二、关于软件工程。
我一直的理解为 软件工程 = 工具 +方法+过程。
想问一下这三者在软件工程实践中的比例大概有个什么比例或者规律什么的。
答：
学界的，尤其是国内学界的讨论中，历来有一个问题。就是讨论一个东西，总是在说“什么是这个东西”，而不是“这个东西是什么”。有些时候，行文上看起来还是前者，实底上却做成了后者。而jazz（提问者）的这个看法，也就存在这样的问题，即是说，您实质上是在说着“把复杂的问题变简单，就是做架构”。这个观点，本质上说是的“怎么做架构”的问题，而并不能解释“架构是什么”，以及“架构怎么做”的问题。
我常说的一个例子，我们去动物园，看到老虎说“这是动物”，又看到狮子也说“这是动物”，再看到鳄鱼还是说“这是动物”。于是我们就可以据此说“老虎+狮子+鳄鱼”就是动物吗？显然这是个笑话了。但我们往往讨论事情的时候就跳不开这个坑，比如说“解决复杂度的问题，就是架构”，并以此来认为这是架构的全部。
很好，我们回到往前一点。架构是什么呢？在我前面的贴子里是没有讲的，而只是讲到了“架构作为一个结果，它由两种东西组成”，以及“架构思维可以由对这两种东西的思考而来”。但这些，我坦承这并不是在解释“架构是什么”。但是，我也不能在这里直接地谈论并给出一个“架构是什么”的答案。正因为我能给出的答案看起来是那样的简单、直接和毫无意义，所以它会被任何人无情地忽略，认为那不过是一句废话。而我在《大道至易》中，对这个答案作出了结构性的分析与解释。我建议任何对这个问题有兴趣的人，去研读这本书的“第十二章 架构原则，技艺、艺术与美”。我在那一章的前言中写着：
我对架构的认识与思想，只是架构可能的认识与思想中的一个方面，是其可能的解中的方式之一。我必须提及这一方面与方式的核心指导原则，这些原则的正确性必将表达为：它可以为其他的认识与思想提供依据，是其他有效的、可供讨论的认识与思想不可违逆的基本前设。本书对架构的谈论，只是这些原则下的一个运用示例；这些原则来源于这些示例的思考过程，并超越于这个过程的结果——本书所讨论的架构。
所以，我希望更为严肃的方式来讨论这个学术性的话题，即是“架构是什么”。而不是“我认为这样做就是做架构”，或“我看到某个架构是这样做的”。我不认为那是答案，并且认为那个方向离答案越行越远。如我此前在“动物园”的比喻中所说的，我们管窥所得的斑斑点点，都不是那个问题的全集或全解；而“管窥”这样的方法，也不是求解的正确方法。
再回复一下您最后的这个问题。简单地说，我认为没有“比例”这样的东西。“软件工程”纯以工学的方式来讲，是有构成与组成的，因为这是它的“问题集”。但在工程实践中，是实践的背景决定了我们如何投入实施力量，而不是一个学术的指导或行事表格。我常说“真正的管理者，是不看管理的技术书的”，当我们把“软件工程”当成一种技术，试图从技术书中找到公式与规则的企图，都死死地陷入在技术思想中，陷入在“工欲善其事，必先利其器”的工匠思维中。
所以我常说“如果你认为这句话对，说明你是‘工’”，因为这原本就是你的工作方法、状态以及你构建知识、能力的基本模式。——引自《大道至易》
