软件设计不是避免变化而是使变化局部化

软件设计不是避免变化而是使变化局部化

一、前言
        在软件开发过程中经常听开发人员抱怨得最多的就是怎么需求又变，之前要求不是这样的。每个版本我们都要求前期分析充分，实际运作时总是遗漏这，遗漏那。有些是在开发过程中发现的，有的在交付用户使用后才发现。

         我们要求一次性把事情做对，实际上常常一次性把事情做错。目标离现实越远，越挫败。我们不是反对前期把需求分析清楚，也不是反对一次把事情做好。事实上我们有很多实践方法来确保一开始把需求弄明确，如敏捷开发，和客户面对面交流，深入客户一线了解客户是怎么开展业务的，也取得了不错的成果。

        需求分析在前端把握大方向，确保产品定位不出问题。更多多如牛毛的细节问题，数量大变化快。是前段分析过程中不易弄清楚的。
        而通过恰当的设计和分析能够将这种变化的影响控制在一定的范围。通读整篇设计模式都是在讲怎么设计以容忍变化，不同的模式能容忍哪些变化。

        软件设计不是避免软件变化而是使软件的变化局部话。这种局部化包括软件修改的局部化和修改后的影响局部化。

二、分析方法
       第一步 理清需求的所有细节，包括已明确的和尚不明确的。对事物的本质理解越透彻，越靠近真理。对不明确的需求分析评估影响，如果影响业务流程的关键点没弄清楚，那么必须停下来弄清楚。

        第二步 一分为二，哪些是不变的，哪些是变化的。不变的是主流程或者底层的公共组件模块。这部分的业务越多说明我们前面分析得越透彻，或者业务很稳定。分析变化部分，考虑没一个变化点，变化的维度及将往哪些方向变化。对每个变化点的不同变化维度你将采用什么方式封装。

         好了，到了这里你苦练的六脉神剑(设计模式)可以派上用场了。

三、总结

        首先尽力把需求分析清楚，同时也要承认我们无法不遗漏任何东西。通过精巧的设计能将变化，不确定带来的影响控制到最小范围。
       

发自我的 Windows Phone