软件开发方法与逻辑-完美软件开发

软件行业中新名词已经多到了让人疯狂的地步，比如：

●框架（Framework），架构（Architecture）。

●面向对象分析和设计（Object Oriented Analysis and Design）。

●设计模式（Design Pattern）。

●契约式编程（Design by Contract）。

●测试驱动开发（Test Driven Development）。

●面向方面的编程（Aspect Oriented Programming）。

●模型驱动架构（Model Driven Architecture）。

●基于组件的开发（Component-Based Development）。

●敏捷软件开发（Agile Software Development）。

●元编程（Meta programming）。

●面向服务的体系结构（Service-oriented architecture）。

●......

可以想象这个列表在可见的未来，仍将无限地增长下去。

就像把狗毛和狗划分为并列的类别会引起思维的混乱一样，对种种新名词如果没有自己的归类体系，那思维很容易陷入混乱，而思维混乱的结局必然是当事人的无所适从—既不知道从哪里开始学习，也不知道究竟应该怎么开始应用学到的东西—这时候往往是既不知道应该做什么，也不知道应该不做什么。

读书或学习的时候，如果自己对待学习的知识有一个大体的认知，那么学到的东西各归其类，学问和见识自然也就会逐渐积累，作为主体的人，其能力也就可以稳步提高，最终的结果就会是：人驾驭知识。

与之相反，当我们对知识的体系没有认知，而零散地学习各个点的时候，就很容易茫然。每个点都是有道理的，但是点与点之间，却可能是有冲突的。这个时候，很可能人的思维会陷入混乱，并最终导致：人被知识所驾驭的局面。

这并不是只属于软件的问题，宗师治学，很多从目录学始。

季羡林先生在《从学习笔记本看陈寅恪的治学范围和途径》一文中说：“中国清代的朴学大师们以及近代的西方学者，研究学问都从书目开始，也以此来教学生。寅恪先生也不例外。他非常重视书目，在他的笔记本中，我发现了大量的书目。比如，笔记本第二本中有中亚书目一百七十种，西藏书目二百种。此外，在好多笔记本中都抄有书目。从二十年代的水平来看，这些书目可以说非常完全了。就是到今天，它仍然有参考价值。”

—摘自豆瓣

但不幸的是，在软件开发这一领域中，暂时还没有目录学这样一种学问，所以软件开发这一领域中仍然保持着混沌状态，纷争不断。为使这种模糊状态减轻一点，在进一步对设计和编码进行展开前，我们需要对设计编码相关的知识大致做一个分类。

本书中预设的前提有一条是：软件是一种固化的思维，而设计和编码是思维固化的过程，在这一过程中开发者需要持续打造概念的边界和定义概念间的逻辑关系。这也就决定了所谓的设计和编码方法只有3个基本选项。

●以逻辑关系为中心，这就是我们常说的结构化分析和设计。

●以概念为中心，这就是我们常说的面向对象分析和设计。(www.xing528.com)

●两者兼顾，这是一直被忽略的，而本书会在后文论及混合模式。

如果把视角再拔高一点就会发现，世界再怎么丰富多彩，但你描述它的时候，基本要素也只是名词（主语）和动词（谓语）。

我们分解世界中问题的时候，要么以名词为中心，要么以动词为中心，要么混合着来。几千年累积的历史可为这一观点的明证。

在软件的世界中，以逻辑为中心大致等价于以动词为中心，以概念为中心大致等价于以名词为中心。

如果上述分析没错，那么各种新技术名词就只能是对结构化分析和设计（以动词为中心）以及面向对象分析设计（以名词为中心）的补充，而绝不是并列的概念。

在2.2.9节中，我们曾经提到了计划（P），实施（D），检查（C），分析（A），改进（I）这5个基本步骤是组织行为中的太极剑法。而各种对结构化分析设计与OO的补充则大致分散在这5个步骤之中。毕竟，设计和编码也是一种组织行为，也需要构建上述的回路，这种回路越敏捷，效率也就越高。虽然很多技术的发起者可能并没有意识到这一点，但他们的工作确实是在使这一回路在设计和编码中运转的更加顺畅。

我们来看两个实例。

●在设计和编码过程中：设计可以大致等价于计划（P），编码可以大致等价于实施（D），测试可以大致等价于检查（C），调试和修正可以大致等价于分析（A）和改进（I）。

契约式编程强调的是规范和检查。在《Design by Contract：原则和实践》一书中作者在前言里写道：

契约式设计的本意很简单，就是在设计和编码阶段向面向对象程序中加入断言（Assertion）。而所谓断言，实际就是必须为真的假设，只有这些假设为真，程序才可能做到正确无误。

对于为什么需要加入断言，进行契约式编程，作者虽未强调，但不难理解，这可以让错误尽早被发现，使设计编码的人可以尽快收到反馈，进行下一步处理。因此，从归类的角度看，契约式编程是对面向对象程序进行实现的一种支持手段。

●我们再来看一下面向方面的编程（AOP）。

这一概念强调的是把业务逻辑和支撑业务逻辑的辅助功能（如日志）分离开来。

记录日志这一动作事实上对每一条业务逻辑都是必须的，这个时候可以选择把记录日志这一行为加到每一个与业务逻辑相关的方法中，也可以分离记录日志这一行为，加入一层代理，在代理中分别调用业务逻辑相关的方法和记录日志的方法。前者会导致记录日志这一行为分散在各个方法中，针对这一问题很多人提出了横切业务逻辑和日志的解决方法，这即是AOP的核心。

从上述描述中我们可以看到，AOP更像是一种模式（范式），实质上是OO的一个补充，而非一个可以和OO并列的知识点，你不能讲AOP生成的对象就不是对象。

通过上述这样的分析，我们可以得到下面这样的归类：

而敏捷则是更大的概念，是利用了分析和设计技术的方法论。

编程的范式（Paradigms）编程的范式是另一个分类的重灾区。如果到Wiki上查，会发现如图7-1所示的可怕列表。

图 7-1

逐个分析每种范式是艰难的，但从分析和设计的角度看，我个人仍持前面所述的观点：要么以概念为中心，要么以逻辑为中心，要么混合。其他的东西是对这种大分类的补充。比如，很有名的泛型（Generic）以及基于此的元编程（Meta Programming）都是对上述3个大分类的补充。但这一观点确实没按照上述这样的列表逐一验证过，主要是这个列表太长，涉及的概念过于繁复。