第7章 什么是敏捷设计

7.1 软件出了什么错

    在软件开发过程中，我们经常发现代码越来越难以维护。需求变化时，很难去修改代码，修改后很容易引起意想不到的bug。在开发初期，程序员尚能清楚地掌握代码，能轻松的进行维护。随着项目地进行，设计越来越复杂，代码越来越混乱，程序员自己也不清楚修改某处代码，是否会引起别的问题。

7.2 设计的臭味——腐化软件的气味

    出现下面任何一种现象，都说明软件正在腐化。

• 僵化性：难以修改代码。每个改动会引起其它改动，牵一发而动全身。
• 脆弱性：对系统的改动，会引起一个在概念上看起来无关的bug。
• 牢固性：各部分代码纠结在一起，很难把一部分代码分离出来进行复用。

      在OOD中，经常会提到“高内聚、低耦合”。僵化性、脆弱性、牢固性的出现，说明系统违背了“高内聚、低耦合”的设计原则。

• 粘滞性：对系统进行改动时，很难维持原来的设计。
• 不必要的复杂性：在设计之初，程序员往往会预测各种可能发生的需求变更，为了适应这些想象的变更，进行了很多超前的设计。在需求确实如预测地那样变更时，这些设计确实有用。但这些预测多数情况下是错误的，这些超前的设计就成了没用的代码，成了系统的累赘，增加了设计的复杂性。
• 不必要的重复性：在实现某个算法时，发现系统中已经有类似的代码了。你不是把这部分代码抽象出来，作为一个函数或类，而是直接copy了一份代码，并做了适当的修改以适应你要解决的问题。这时候你应当祈求这个算法不要发生bug，因为发生bug后你需要去修改每个算法copy，更不幸的是这些copy并不完全相同，你为了适应每个问题而做了修改。不必要的重复性降低了程序的可维护性。
• 晦涩性：代码难以理解，不够清晰。应当通过添加注释、优化代码结构来增加代码的可读性。最重要的一点：站在代码阅读者的角度审查代码。

7.2.1 什么激发了软件的腐化

 

    项目之处，设计能够很好的满足需求。随着项目的进行，需求不断变更，而且变更方向偏离了设计，设计已经不能满足需求。程序员不得不进行破坏原来设计的修改。虽然修改后的系统能正常工作，但已经违反了原来的设计，为软件腐化埋下了种子。

7.2.2 敏捷团队不允许软件腐化

    不要抱怨需求的变更破坏了你的设计。记住：用户永远是对的，需求一定会变化，而且变化方向是难以预测的。敏捷团队几乎不预测需求的变更方向，不为预测的变更进行超前的设计。在需求变更成为现实时，才去修改设计。这是一个迭代的过程，每个迭代中，程序员根据最新的需求修改设计，在每次迭代结束后，当前的设计都是贴切地符合当前需求的。敏捷程序员不会幻想在项目之初进行设计，然后一直保持这个设计到项目结束。It's impossible!

 

7.3.2 怎样做一个敏捷开发人员

 

• 遵循敏捷实践去发现问题
• 应用设计原则去诊断问题
• 应用设计模式去解决问题

7.4 保持尽可能好的设计

    敏捷开发人员致力于保持设计恰当、干净。换言之，保持设计贴切地符合需求。需求变更出现后，如果当前的设计不能满足（这个变更是第一颗子弹），立即修改设计，使设计满足当前需求，且满足类似的需求变更。敏捷开发人员绝对不允许腐化出现。

 

7.5 结论

    敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式及实践来改进软件结构和可读性的过程。它致力于保持系统设计在任何时候都能贴切地满足当前需求。