敏捷设计之拙劣设计的症状（摘录）

摘录自：敏捷软件开发

1.僵化性(Rigidity)： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
2.脆弱性(Fragility)： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3.牢固性(Immobility)： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
4.粘滞性(Viscosity)： 做正确的事情比做错误的事情要困难。
5.不必要的复杂性(Needless Complexity)： 设计中包含有不具任何直接好处的基础结构。
6.不必要的重复(Needless Repetition)： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
7.晦涩性(Opacity)： 很难阅读、理解。没有很好地表现出意图。

Rigidity
僵化性是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。如果做过系统维护，那么对这种情况就应该熟知了。Rigidity is the tendency for software to be difficult to change, even in simple ways. A design is rigid if a single change causes a cascade of subsequent changes in dependent modules. The more modules that must be changed, the more rigid the design.
 Most developers have faced this situation in one way or another. They are asked to make what appears to be a simple change. They look the change over and make a resonable estimate of the work required. But later, as work though the change, they find that there are repercussions to the change that they hadn't anticipated.  They find themselves chasing the change through huge portions of the code, modifying far more modules than they had first estimated. In the end, the changes take far longer than the initial estimate. When asked why their estimate was so poor they repeat the traditional software developer's lament, "It was a lot more complicated than I thought!"

Fragility
在进行一个系统改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题又会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗样（忙得团团转）。随着模块脆弱性的增加，改动会引出意想不到的问题的可能性就越来越大。这看起来很荒谬，但是这样的模块是非常常见的。这些模块需要不断的修补——它们从来不会被从错误列表中去掉，开发人员知道需要对它们进行重新设计，你越是修正它们，它们就变得越糟糕。

Immobility:
设计中包含了对其它系统有用的部分，但是要把这部分从系统中分离出来所需要的努力和风险是巨大的。

Viscosity：难以做正确的事情
两种表现形式：软件的粘滞性和环境的粘滞性。当面临一个改动时，开发人员常常会发现有多种改动的方法。其中一些方法会保持设计，另外一些方法会破坏设计（也就是生硬的方法）。当那些保持设计的方法比那些生硬手法更难以使用时，就表明设计具有高粘滞性。当开发环境迟钝、底效时，就会产生环境的粘滞性。

Needless Complexity：过分设计

如果设计中包含有当前没有用的组成部分，它就含有不必要的复杂性。当开发人员预测需求大额变化，并在软件中防止了处理哪些潜在变化的代码时，常常会出现这种情况。起初，这样做看起来象是一件好事。糟糕的是结果常常相反。为过多的可能性做准备，致使设计中包含绝对不可能用到的结构，从而变得混乱。一些准备会带来回报，但是更多的是不会。期间，设计背负着这些用不到的部分使软件变得复杂，并且难以理解。

Needless Repetition：滥用鼠标（乱拷贝）

剪贴和粘贴常常使软件系统都是构建于众多的重复代码片断之上。
当同样的代码以稍微不同的形式一再出现时，就表示开发人员忽视了抽象。对于开发人员而言，发现所有的重复并通过适当的抽象来削除它们的做法可能没有高的优先级别，但是这样做非常有助于使系统更加易于理解和维护。
当系统中有重复的代码时，对系统改动会变得困难。在一个重复的代码体中发现的错误必须要在每个重复体中一一修正。不过，由于每个重复体之间都有细微的差别，所以修正的方式也不总是相同的。

Opacity：混乱的表达

是指模块难以理解。代码可以用清晰、富有表现力的方式编写。或者可以用晦涩、费解的方式编写。代码随着时
间而演化，往往会变得越来越晦涩。 为了使代码的晦涩性保持最低，就需要持续的保持代码清晰并富有表现力。

 

需求是项目中最不稳定的因素。如果设计由于持续、大量的需求变化而失败，就表明我们的设计和实践本身是有缺陷的。我们必须找到一种方法，使得设计对于这种变化具有弹性，并且应用一些实践来防止设计腐化。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。它们更愿意保持系统设计尽可能的干净、简单、并使用许多单元测试和验收测试作为支援。（这里就有一个问题，如果事先不进行较完善的设计，那么，当核心需求（或者说是基础需求）变动后，就意谓着全局设计的改变，这就意味着几乎整个系统都需要重构。我以为，初始的设计之前，应该至少需要对系统全局有很深刻的把握。敏捷开发在一些模块化的设计中，有更持续的活力）