【转】 代码设计敏捷开发三部曲

【转】 代码设计敏捷开发三部曲

1、敏捷开发与MVP

1.mvp

Eric Ries曾在《精益创业实战》中提出MVP（minimum viable product）概念，意即“最简可行产品”——用最快、最简明的方式创建一个可用的产品原型，这个原型要表达出你产品最终想要的效果，而后经过迭代来完善细节

从如今敏捷开发的角度来说，这是快速迭代产品的最最好方式之一就是mvp，不求大而全。

2.敏捷开发三部曲：《设计模式》-> 《重构》-> 《重构与模式》。也就是设计->重构->重构出新设计。

《设计模式》主要详细说明20几种模式，为咱们带来了常见设计问题的经典解决方案，从而改变了整个面向对象开发的面貌。为设计而著。

《重构》改善既有代码的设计，总结了咱们会用到的各类重构手法，为咱们带来了一种改进代码的高效过程，从而完全改变了面向对象设计的方式。侧重去除坏代码的味道。

《重构与模式》是设计模式相关的重构。模式不是设计出来的，是重构出来的。好的设计也不是设计出来的，是重构出来的。不要怕改变，只要改变得法，变就再也不是灾难，而是进步的良机。侧重设计模式+重构手段。

在阅读重构与模式以前，最好熟读前面两本：《设计模式》和《重构》。

设计模式表明了传统的软件开发思想：好的设计会产生好的软件，所以在实际开发以前，值得花时间去作一个全面而细致的设计。重构表明了敏捷软件开发的浪潮：软件并非在一开始就能够设计得天衣无缝的，所以能够先进行实际开发，而后经过对代码不断的进行小幅度的修改来改善其设计。两者从不一样角度阐述了设计的重要性。

有些人在编写任何代码以前，都要很早地为模式作计划，而有些人在编写了大量代码以后才开始添加模式。

第二种使用模式的方式就是重构，由于是要在不增长系统特性或者不改变其外部行为的状况下改变系统的设计。

有些人在程序中加入模式，只是由于以为模式可以使程序更容易修改；更多人这样作只是为了简化目前的设计。

若是代码已经编写，这两种情形都是重构，由于前者是经过重构使修改更容易，然后者则是经过重构在修改后进行整理。

虽然模式是在程序中可以看到的东西，可是模式也是一种程序转换。

重构是实现设计模式的一种手段，设计模式每每也是重构的目的。

2、重构与模式的原因

应该经过重构实现模式、趋向模式和去除模式(refactoring to, towards, and away from pattern)，而不是在预先设计中使用模式，也再也不过早的在代码中加入模式。这技能避免过分设计，又不至于设计不足。

1.过分设计

代码的灵活性和复杂性超出所需。有些开始设计的时候，认为某些地方会频繁的改动，甚至开始使用了某种设计模式预留扩展，可是后来却没怎么动，也就是致使了废设计和功能.。

2.设计不足

产生设计不足的缘由：

1）程序员没有时间，没有抽出时间，或者时间不容许进行重构

2）程序员在何为好的软件设计方面知识不足

3）程序员被要求在既有系统中快速的添加新功能

4）程序员被迫同时进行太多项目

长期的设计不足，会使软件开发节奏变成“快，慢，更慢”，可能的后果是：

1.0版本很快就交付了，可是代码质量不好

2.0版本也交付了，但质量低劣的代码使咱们慢下来

在企图交付将来版本时，随着劣质代码的倍增，开发速度也愈来愈慢，最后人们对系统、程序员乃至使你们陷入这种境地的整个过程都失去了信心

到了4.0版本时或者以后，咱们意识到这样确定不行，开始考虑推倒重来。

3.测试驱动开发和持续重构

测试驱动开发和持续重构提供了一种精益、迭代和训练有素的编程风格，可以最大程度的有张有弛，提升生产率。“迅速而又从容不迫”

使用测试驱动开发和持续重构的益处：

1）保持较低的缺陷数量

2）大胆的进行重构

3）获得更加简单、更加优秀的代码

4）编程时没有压力

模式和重构之间存在着自然联系，模式是你想达到的目的地，而重构则是从其余地方抵达这个目的地的条条道路。

4.演进式设计

演进式设计即趋向性设计，主要是避免过分设计。

经过重构产生设计结构，也就是经过重构实现模式或者重构趋向模式。为设计而设计的思路并不适合大项目，按部就班从重构到设计模式才是设计模式的王道。

敏捷开发中常常采用的演进式架构设计：

不少程序员可能都碰见过这种事：某块代码亟待修改，却没有人愿意接手。为何会这样？这段代码正巧是两个组件间的接口，修改工做太过困难。而在演进式设计中，咱们经常会作这种修改。代码应当是"活的"而且是"可生长"的，决不能无视强烈的变化需求 而保持一成不变。正由于如此，演进式设计能够提升设计质量，进而提升整个系统的质量。

 

 

 

本文转自：一点资讯

微信号：IdeaofSE