By 高焕堂 2011/09/04
[ IT史上最完整、最经典的软件框架开发技术宝典 (上百篇经典文章&eBooks) ]
[Go Back]
内容
- 敏捷软件开发的原则
- 敏捷架构设计(Agile Architecture Design)
- 中层设计与EIT软件造形
1. 敏捷软件开发的原则
敏捷(Agile)概念来自于软件行业。由于软件开发项目的成功率偏低，以北美地区为例，有30%的项目未完成就取消了，大多数的项目费用几乎超过预估的两倍，这些危机，主要是因为开发软件费时费力，而且客户需求复杂而持续演变，让传统固定流程的开发途径面临巨大的困难。
因此，于2001年2月11-13日，在美国犹他州的Snowbird镇有17位方法学专家聚会研议，共同发表所谓「敏捷宣言」(The Agile Manifesto)，宣言包含有4项基本原则，如下：
◆ Individuals and interactions over processes and tools
(人员交流重于过程和工具)
◆ Customer collaboration over contract negotiation
(客户协作重于合同谈判)
◆ Working software over comprehensive documents
(可用软件重于完备文件)
◆ Responding to change over following a plan
(包容改变重于遵循计划)
其中，”over” 意味着传统上太重视右边，如今右边仍然有其价值，只是在敏捷观念中，特别关切左边，来平衡过度依赖右边的副作用。这四项宣言特别关注于人的角色；其中，前两项宣言聚焦于：沟通合作(Communication & Collaboration)；而后两项则聚焦于：检验反馈(Test & Feedback)。基于上述原则，衍生出敏捷开发过程的主要概念：
- 最简方案(Simplest solutions)
- 迭代过程(Iterative process)
- 重构(Re-factoring)
- 持续整合(Continuous integration)
虽然敏捷思维是源自软件(代码)开发行业，在宣言里特别强调”可用的软件(代码)”；然而，上述的2个焦点：<沟通合作>和<检验反馈>；以及4个过程概念都适用于各行业的规划、设计、开发与建置的团队合作活动。如下图所示：
图-1 敏捷的基本迭代过程
此图表示出，依循敏捷过程，以测试驱动(TDD, Test-Driven Development)引导出持续地反馈(Feedback)与迭代(Iteration)的软件开发过程。基于愿景而设计足够好(Good Enough)的简单方案，做为基础，尽快将设计落实成为代码；然后以需求来进行检测，将测试结果反馈回来，修正和重构设计和代码，持续迭代循环下去。于此，我来引用著名软件架构师Fred George的话，他曾说：
”Kent Beck曾经说：<代码就是设计与残酷现实(需求)的明暗交汇點>。他的意思是，我们能画出许多美好的设计，但最好的设计仅仅是被翻译为优雅代码的那些。一个无法将愿景(即Vision)带入代码的架构师将无法洞悉这个急速变化城市所呈现的面貌。”
“Code is when design meets the harsh reality of dawn.” He was saying that all designs look pretty when we draw them, but the best design translates into elegant code. The architect that doesn’t carry his vision into code will never gain the insights that our changing industry exhibits.
透过TDD来驱动敏捷迭代过程，迅速将愿景带入代码里，透过及时反馈促进人员的大量沟通，迅速重构设计(含调整愿景)和代码，以便敏捷地响应外在环境和需求的瞬息变化。
2. 敏捷架构设计(Agile Architecture Design)
上一节所谈的敏捷原则和过程，并没有明显地区分<架构设计阶段>与<代码开发阶段>；而是融合在一个迭代范围里。那么，如果有必要将上述两个阶段切分开来时，变成两个迭代范围时，又该如何运作呢?
首先我来谈谈如何将敏捷迭代&反馈机制应用于设计阶段。架构设计阶段与代码开发阶段的主要区别是：相对上，架构设计阶段创意空间较大，因而对愿景(Vision)的依赖比依赖比较大；而代码开发阶段则对需求(Requirements)的依赖的比较大。
两阶段敏捷迭代之间的衔接
首先，回顾上图-1里的传统敏捷开发过程。然后将其”设计”区分为两部分：<架构设计>与<细部设计>；如下图所示：
图-2 将传统的”设计”分为两部分
这两个阶段，几乎都是先进行<架构设计阶段>，然后才进行<细部设计阶段>。这两阶段之间有些时间的落差。如下图所示：
图-3 两阶段之间的时间间隙
由于两者时间先后不一致，两者之间有时间间隙，使得代码开发阶段的敏捷迭代(Iteration)机制无法覆盖到架构设计。于是，一个巨大的难题出现了：如何确保架构设计的<可实现性>呢? 于是，我独创了一个新的层级：中层设计。这个<中层设计>是软件接口定义层，用意在于使用软件开发的TDD(Test-Driven Development)分法来检验架构设计里最关键的<接口>(Interface)部分，为系统整合进行测试；提升架构的整体和谐，及其可落地性。
在架构设计阶段，依循敏捷途径，以测试驱动(Test-Driven)引导出持续地反馈(Feedback)与迭代(Iteration)的中层设计(即软件接口开发)过程。如下图-4所示。
图-4 <架构设计阶段>的敏捷迭代过程
经由敏捷TDD机制来执行接口软件，实际检测信息交换的所需的软硬整合设备，以及相关通信机制。产出计算机可执行的软件接口控制代码，就是中层设计的作品了。
到了将来软件开发阶段，上述中程设计所产出的软件接口代码，就交付给软件开发团队，结合其细节设计，一起参与开发阶段的敏捷迭代过程。中层设计是在<架构设计阶段>所完成的，属于<架构设计阶段>的工作范围。到了<代码开发阶段>，我们将会拿中层设计所产出的软件代码，来做为软件开发阶段的基础；也就是开发阶段进行敏捷迭代过程的单纯起点，在敏捷开发概念里，称为：简单方案(Simple Solution)；如下图：
图-5 <代码开发阶段>的敏捷迭代过程
由于架构设计的决策必须具备未来性，此时敏捷思维里的迭代、反馈与沟通(合作)，是架构设计过程中必须具备的<敏捷性>。敏捷架构设计与敏捷开发，其实是可以分阶段，并且能透过中层设计来做无缝隙的衔接。于此，我套用前面(第1节里)Fred George的说法，成为：
“架构是远景与残酷现实(需求)的黎明交汇。我们能想象出许多美好的愿景，但最好的愿景仅仅是被翻译为优雅架构设计的那些。一个无法将愿景带入架构的顶层设计师将无法洞悉这个急速变化城市所呈现的面貌。”
从上图-4和图-5可以看到，这两个阶段的衔接是很和谐流畅的。敏捷思维的核心是：以跌代(Iterative)过程带动反馈；以反馈促进沟通(与合作)。这项思维非常适合于架构设计，于是两个阶段的迭代思维是一致的，也就很容易(透过中层设计)将传统软件开发的敏捷思维和原则扩大到大型系统的架构设计。
3. 中层设计与EIT造形
敏捷开发过程的主要概念是：1) 最简方案(Simplest solutions)；2)迭代过程(Iterative process)；3)重构(Re-factoring)；4)持续整合(Continuous integration)
其中的第一项：最简方案，就是从一个足够好的简单起点出发，进快启动迭代&反馈过程。为了满足实践阶段的迭代过程的要求，我独创了一个超级简单的软件造形，称为：EIT软件造形。一方面，它能完全表达中层设计的软件接口结构，能立即落实为代码，让顶层设计阶段能尽快展开敏捷迭代过程，并能产出计算机可执行的接口定义代码。另一方面，此EIT造形既足够表达顶层的互联互通的接口定义，又非常简单。刚好满足敏捷的<足够好又简单>的起点要求。此EIT造形如下：
图-6 高焕堂设计的EIT软件造形
一旦中层设计与EIT造形结合之后，其整体架构就如下图所示：
图-7 高焕堂设计的><中层设计+EIT造形>
造形是软件<集装箱>，代码开发人员可以将软件代码直接添加到中层设计的EIT造形里。而且能设计EIT造形幕后的形形色色软件代码，来处理细节计算。所以，中层设计里的EIT造形的创意组合结构，能顺利成为实践层的主架构(Architecture)。基于这个主架构，实践层的架构师可以增添较为细节的设计规范，包括软件、硬件平台的选择、数据库设计、代码测试方案、性能优化设计等实践层级的细节考虑；成为软硬整合的系统架构。
软件造形所创造的简洁性，就可针对各系统之间互联互通的接口部分，以明确的软件代码来定义之；以唐代”诗同形”途径来提升架构设计(和中层设计)的<明确性>。才能有效检验架构设计的<可实现性>。愈大规模的系统开发，其中层设计就愈重要；而造形则扮演核心角色。因为它为上、中、下层人员开创设计概念的一致性(Conceptual integrity)，让他们获得一致的共识(Shared understanding)。◆
2129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
