一、敏捷开发与MVP
1.mvp
Eric Ries曾在《精益创业实战》中提出MVP(minimum viable product)概念,意即“最简可行产品”——用最快、最简明的方式建立一个可用的产品原型,这个原型要表达出你产品最终想要的效果,然后通过迭代来完善细节
从现在敏捷开发的角度来讲,这是快速迭代产品的最最好方式之一 就是mvp,不求大而全
2.敏捷开发三部曲:《设计模式》-> 《重构》-> 《重构与模式》。也就是设计->重构->重构出新设计。
《设计模式》主要详细说明20几种模式,为我们带来了常见设计问题的经典解决方案,从而改变了整个面向对象开发的面貌。为设计而著。【图书介绍:HEAD_FIRST设计模式,四人帮设计模式】
《重构》改善既有代码的设计,总结了我们会用到的各种重构手法,为我们带来了一种改进代码的高效过程,从而彻底改变了面向对象设计的方式。侧重去除坏代码的味道。【图书介绍:重构改善既有代码的设计】
《重构与模式》是设计模式相关的重构。模式不是设计出来的,是重构出来的。好的设计也不是设计出来的,是重构出来的。不要怕改变,只要改变得法,变就不再是灾难,而是进步的良机。侧重设计模式+重构手段。【图书介绍:重构与模式】
在阅读重构与模式之前,最好熟读前面两本:《设计模式》和《重构》。
第二种使用模式的方式就是重构,因为是要在不增加系统特性或者不改变其外部行为的情况下改变系统的设计。
有些人在程序中加入模式,只是因为觉得模式能够使程序更容易修改;更多人这样做只是为了简化目前的设计。
如果代码已经编写,这两种情形都是重构,因为前者是通过重构使修改更容易,而后者则是通过重构在修改后进行整理。
虽然模式是在程序中能够看到的东西,但是模式也是一种程序转换。
重构是实现设计模式的一种手段,设计模式往往也是重构的目的。
应该通过重构实现模式、趋向模式和去除模式(refactoring to, towards, and away from pattern),而不是在预先设计中使用模式,也不再过早的在代码中加入模式。这技能避免过度设计,又不至于设计不足。
1)程序员没有时间,没有抽出时间,或者时间不允许进行重构
3)程序员被要求在既有系统中快速的添加新功能
4)程序员被迫同时进行太多项目
长期的设计不足,会使软件开发节奏变成“快,慢,更慢”,可能的后果是:
1.0版本很快就交付了,但是代码质量很差
2.0版本也交付了,但质量低劣的代码使我们慢下来
在企图交付未来版本时,随着劣质代码的倍增,开发速度也越来越慢,最后人们对系统、程序员乃至使大家陷入这种境地的整个过程都失去了信心
到了4.0版本时或者之后,我们意识到这样肯定不行,开始考虑推倒重来
敏捷开发中经常采用的演进式架构设计:
很多程序员可能都遇见过这种事:某块代码亟待修改,却没有人愿意接手。为什么会这样?这段代码正巧是两个组件间的接口,修改工作太过困难。而在演进式设计中,我们常常会做这种修改。代码应当是"活的"并且是"可生长"的,决不能无视强烈的变化需求 而保持一成不变。正因为如此,演进式设计可以提高设计质量,进而提高整个系统的质量。