|
如何更好地进行软件架构设计这是软件工程领域中一个永恆的重点话题过去几十年来国际软件工程界在软件架构设计方面已经获得了长足发展大量图书文章和文献记载了这方面的成熟经验与成果软件架构设计往往是一件非常复杂的工作涉及到很多细节和方方面面可探讨的话题也非常之多囿于篇幅限制以下只能根据笔者个人理解遴选出软件架构设计的个别要点结合当前流行的敏捷软件工程思想与大家分享一下自己在软件架构设计方面的心得和体会 架构决定成败 软件架构是软件产品软件系统设计当中的主体结构和主要矛盾任何软件都有架构哪怕一段短小的HelloWorld程序软件架构设计的成败决定了软件产品和系统研发的成败软件架构自身所具有的属性和特点决定了软件架构设计的复杂性和难度 这几年流行一个说法（管理谚语）细节决定成败这句话其实只说对了一半细节确实很重要很多项目产品就输在细节的执行上一方面战术细节固然很重要但另一方面战略全局也同样重要对应的我们可以说战略决定成败战略性失败就好比下一盘围棋局部下得再漂亮再凌厉如果罔顾大盘己方连空都不够了还有官子（细节）获胜的机会吗？必然是中盘告负 类似地正确的软件架构设计应该既包括战略全局上的设计也包括战术细节（关键路径）上的设计有一种错误的观点认为软件架构设计只要分分层和包画一个大体的轮廓草图就完事了这种纸上谈兵型的架构师行为是非常有害的事实上既然软件架构是软件建筑的主体结构隐蔽工程承重墙和要害部位那么软件架构也必然要落实到实际的算法和代码不但要有实现代码还要包括对这部分架构进行测试的代码以保证获得高质量的满足各种功能和非功能质量属性要求的架构除了完成概念模型设计外软件架构师一定要参与实际的编码测试和调试做一位真正的handson practitioner这已经成为了敏捷软件工程所倡导的主流文化 两个架构 我们在日常的软件产品和系统开发中实际上会遇到两种两个部分的软件架构即待开发的应用部分的软件架构（简称应用架构）以及既有的基础平台部分的软件架构（简称基础架构）这两部分架构之间是互为依赖相辅相成的关系它们共同组成了整个软件产品和系统的架构 基础架构的例子包括NET和JEE等主流的基础平台和各种公共应用框架由基础库API对象模型事件模型各种开发和应用的扩展规则等内容组成我们只有熟悉基础架构的构造细节应用机理才能有效地开发出高质量高性能的上层应用然而开发一个面向最终用户的软件应用系统和产品仅仅掌握一般的计算机高级编程语言知识和基础平台架构API的使用知识显然是不够的我们还需要根据客户应用的类型和特点在基础架构之上设计出符合用户要求的高质量应用软件 熟悉OOAOOD抽象建模技术设计原则以及架构模式和设计模式等等方法技术不但有助于我们更好地理解和利用基础平台架构也有助于我们设计开发出更高质量的应用软件架构 风险驱动敏捷迭代的架构设计与开发 软件架构将随着软件产品和系统的生命周期而演化其生命期往往超过了一个项目一次发布甚至有可能长达数年之久因而软件架构无论对于客户还是开发商来说都是一项极其重要的资产 软件架构的设计应该遵循什么样的开发过程？或者说有没有更好的成熟的软件架构设计和开发过程？回答是世纪的软件架构设计应该优先采用敏捷迭代的开发方式和方法与传统做法不同敏捷迭代开发主张软件架构采用演进式设计（evolutionary design）一个软件产品或系统的架构是通过多次迭代乃至多次发布在开发生命周期中逐步建立和完善起来的 好的软件架构不是一蹴而就的在架构设计开发过程中我们应该尽量避免瀑布式思维通过一个架构设计阶段来完成系统的架构设计乃至详细设计然后再根据架构图纸和模型在编码实现阶段按图索骥进行架构的编码与实现这种传统做法的错误在于认为软件架构就是图纸上的模型而不是真正可以高质量执行的源代码几十年的软件工程实践表明没有经过代码实现测试用户确认过的架构设计往往会存在着不可靠的臆想猜测和过度设计过度工程极易造成浪费和返工导致较高的失败率 风险是任何可能阻碍和导致软件产品/系统研发失败的潜在因素和问题软件架构是软件产品和系统研发的主要矛盾和主要技术风险软件架构的质量决定了整个软件系统和产品的质量不确定性往往是软件架构设计当中一种最大的潜在风险因此软件架构的设计与开发应该遵循风险驱动的原则在整个开发生命周期内至始至终维护一张风险问题清单随着迭代的前进根据风险的实时动态变化首先化解和处理最主要的架构风险再依次化解和处理次要的架构风险 架构设计的可视化建模 软件架构设计的难度源于软件设计问题本身的复杂性一个复杂的软件系统往往存在大量复杂的难于被人类所理解的细节和不确定因素抽象与建模是人类自诞生以来就已掌握的理解复杂事物的方法因而人类所从事的软件设计工作本质上也是一个不断建模的过程我们可以通过各种抽象的模型和视图从各个不同层次宏观和微观的角度来理解复杂的软件架构以保证作出正确和有效的设计 有人认为软件架构就是源代码（source codes）以及源代码就是设计这种说法其实是片面的什么是真正的软件？我们知道最终可以在电脑上执行的真正的软件其实是二进制代码和借助编译器我们把高级编程语言翻译成底层的汇编语言机器语言等没有人能直接完整地看到二进制程序在CPU上的实际运行状况（runtime）人们大多只能通过各种调试工具窗口视图等方式来间接地动态观察这些真正的软件的运行片段因此JavaC#C++ 等等设计时（design time）源代码在本质上也是一种模型虽然是一种经处理后可执行的静态模型但显然它们并不是真实软件和软件架构的全部可见源代码模型（有时也叫实现模型）与UML模型其实都是软件架构的一种模型（逻辑反映）差别就在于抽象层次的不同完整的软件架构（建筑）不仅仅包括源代码（实现模型）还包括了需求模型分析模型设计模型实现模型和测试模型等等许多模型软件架构本身就是一组模型的集合 UMLSysML是当前国际上流行的软件/系统架构可视化建模语言在编写实际的代码之前利用包图类图活动图交互图状态图等等各种标准图形符号对软件架构进行建模探讨和交流各种可行的设计方案发现潜在的设计问题保证具体编码实现之前抽象设计的正确性被实践证明是一种非常有效和高效敏捷的工作方式 架构设计的重用 重用（Reuse）是在软件工程实践中获得高效率高质量产品和系统开发的一种基本手段和主要途径通过有组织的系统和有效的重用我们往往可以获得倍率以上的效率提升而一个优秀的有长久生命力的软件架构（比方主流的一些框架软件）其本身或其组件被重用的次数越多其体现的价值也就越大 软件重用有各种不同的范围层次粒度和类型从函数重用类重用构件/组件重用库（API）重用到框架重用架构重用模式重用再到软件设计知识思想的重用等等重用的效能和效果各有不同 软件工程经过几十年的发展已经积累了大量的软件架构模式和设计模式它们记载蕴藏了大量成熟已经验证的软件设计知识思想和经验我们平时对各种基础平台主流框架和API的应用和调用本身就是一种最为普遍的重用形式而一个优秀成熟的软件研发组织必然会在日常开发中注意收集各种软件设计知识和经验建立和维护基于架构模式和设计模式等内容的软件重用知识库积极主动和频繁地运用各种软件模式来解决实际工程问题 框架（Framework）是一类具有高可重用度的软件针对某一类应用或领域它们具有非常灵活的高度可扩展的软件架构那么如何才能设计出可重用的软件架构或其组件？借助于OOAOOD等抽象分析和设计技术是一种重要的方法人们在实践中发现往往越抽象的东西其适应面也就越广可重用度也就越高相反越具体的东西其适应面也就越窄可重用度也就越低重用意味着充分利用现成既有的东西成果来解决新问题或重复的问题以不变应万变在软件架构设计中应该主动地区分软件架构中的不变与可变之处系统地管理好这些稳定点和变化点以适应未来的变化这也是提高软件架构重用度获得高质量框架设计的一种重要方法 架构设计的权衡 与其它所有工程行业一样软件工程本质上也是一门讲究权衡的科学和艺术软件架构设计的最难之处往往在于如何在各种相互竞争矛盾的制约条件之下作出巧妙的最佳权衡软件架构设计的权衡水平也是最能体现软件架构师的设计经验能力和技巧的地方 在软件开发和软件架构的设计过程中从选择平台到选择语言选择框架选择设计模式选择工具…等等我们无时不刻都需要权衡对各种候选项作出合理评判在架构师带领下软件研发团队往往还需要对近期目标与远期目标质量与速度和效率质量与成本功能与性能灵活性与复杂性…等等许多彼此矛盾的设计选项因素和约束进行细致小心和理性的权衡 理性权衡意味着科学决策进行有效的架构设计权衡离不开科学的方法也就是如何运用定量分析和定性分析相结合的方法因果逻辑和根源分析等等技术找到最终的甜点（Sweet Spot）许多时候能否在很短的时间内作出迅速果断而正确的科学权衡与取捨决策构成了一个软件研发团队核心竞争能力的一部分 |
