小步快跑是这样玩的（下）

系统重构到这一步，我们来看看用户关于时间问候语部分的变更需求：问候需要更加精细，如中午问候“Good noon! ”、傍晚问候“Good evening! ”、午夜问候“Good midnight! ”。除此之外，用户希望在一些特殊的节日，如新年问候“Happy new year! ”、情人节问候“Happy valentine’s day! ”、三八妇女节问候“Happy women’s day! ”，等等。此时我们发现，我们对时间问候语的变更不再需要修改HelloWorld或其它什么类，而是仅仅专注于修改GreetingAboutTime就可以了，这就是因重构带来的改善。

同时，我们发现，过去只需getHour()就足够，而现在却需要getMonth()与getDay()。随着程序复杂度的提升，我们适时进行了一次重构，将与时间相关的程序抽取到一个新类DateUtil中，就可以顺利地改写原有的时间问候语程序：

/**
 * The utility of time
 * @author fangang
 */
public class DateUtil {
	private Calendar calendar;
	/**
	 * @param date
	 */
	public DateUtil(Date date){
		calendar = Calendar.getInstance();
		calendar.setTime(date);
	}
	/**
	 * @return the hour of day
	 */
	public int getHour(){
		return calendar.get(Calendar.HOUR_OF_DAY);
	}
	/**
	 * @return the month of date
	 */
	public int getMonth(){
		return calendar.get(Calendar.MONTH)+1;
	}
	/**
	 * @return the day of month
	 */
	public int getDay(){
		return calendar.get(Calendar.DAY_OF_MONTH);
	}
}

/**
 * The greeting about time.
 * @author fangang
 */
public class GreetingAboutTime {
	private Date date;
	public GreetingAboutTime(Date date){
		this.date = date;
	}
	/**
	 * @return the greeting about time
	 */
	public String getGreeting(){
		DateUtil dateUtil = new DateUtil(date);
		int month = dateUtil.getMonth();
		int day = dateUtil.getDay();
		int hour = dateUtil.getHour();
		
		if(month==1 && day==1) return "Happy new year! ";
		if(month==1 && day==14) return "Happy valentine's day! ";
		if(month==3 && day==8) return "Happy women's day! ";
		if(month==5 && day==1) return "Happy Labor day! ";
		......
		
		if(hour>=6 && hour<12) return "Good morning!";
		if(hour==12) return "Good noon! ";
		if(hour>=12 && hour<19) return "Good afternoon! ";
		if(hour>=19 && hour<22) return "Good evening! ";
		return "Good night! ";
	}
}

最后，我们建立user表存放用户信息，创建UserDao类为GreetingToUser提供用户信息访问的服务；我们将greetingRule表存放问候语库，创建由GreetingRuleDao接口及其实现类，为GreetingAboutTime提供一个可扩展的、支持多语言的问候语库（如图）。所有这一切都是在现有基础上，通过小步快跑的方式一步一步演变的。



小步快跑是一种逐步进化式的程序设计过程，它要求我们不要一次做太多的设计，不要想着一步到位完成开发。每次完成一个小设计，实现一个小需求，对原有系统进行一个小修改，然后立即运行、测试、验证。它是一个十分新颖的概念，也许你一时半会儿还不能完全领悟，或者欣然接受，因为它太前卫了，与我们传统的思维大相径庭。然而，没有关系，就像一部精彩的小说需要慢慢揭开它神秘的面纱，你会慢慢领悟，终会接受。总之，活在当下，做现在的设计，将来的事情将来再考虑。（续）

相关文档
遗留系统：IT攻城狮永远的痛
需求变更是罪恶之源吗？
系统重构是个什么玩意儿
我们应当改变我们的设计习惯
小步快跑是这样玩的（上）
小步快跑是这样玩的（下）
代码复用应该这样做（1）
代码复用应该这样做（2）
代码复用应该这样做（3）
做好代码复用不简单（1）

特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！

评论

13 楼 songzhan 2014-01-17  

看完文章，有了新的体会，谢谢LZ

12 楼 fangang 2014-01-17  

jackra 写道

感觉像是炒概念
有神马新鲜的地方？

其实我没有炒任何新概念，重构是既有的概念，小步快跑是英文原文做的更加生动贴切的翻译。文中我是通过示例，让大家明白这种开发模式真正的含义，如何运用。

如果通过我的讲解，对大家的设计有所帮助，目的就达到了。炒不炒概念，这都是浮云，有神马意义呢？

11 楼 fangang 2014-01-17  

rlplyyrb 写道

感觉这种做互联网还行，银行系统肯定不能这样搞，流程太死，不能说想让你重构就重构的，想让你怎么改就怎么改的。

其实大家一提到重构，首先想到的是大范围的、架构层面的大修改，然而这只是重构的一种。这种重构称为“大重构(Big Refactoring)”，其实应用并不广泛。
文中我所倡导的是另一种重构，一种小范围的重构。试想，不论流程多死，你能修改代码吗？要实现新功能不可能不修改代码，至于怎样修改，你说了算，是不是？这就对了，你可以选择原始的修改方式，也可以选择优秀的、重构的修改方式，这是你的选择。
其实单位也很郁闷，制定各种制度限制代码修改，是担心糟糕设计的出现。如果都能做出优秀的设计，谁会阻止呢？

10 楼 rlplyyrb 2014-01-16  

感觉这种做互联网还行，银行系统肯定不能这样搞，流程太死，不能说想让你重构就重构的，想让你怎么改就怎么改的。

9 楼 fangang 2014-01-16  

fly_宇光十色 写道

博主一定看过《重构》这本书 

必须的

8 楼 fly_宇光十色 2014-01-16  

博主一定看过《重构》这本书 

7 楼 fangang 2014-01-15  

xiaozhi6156 写道

是不是我可以这样子理解，刚开始的时候，就不必要做太多的架构的东西，而且随着系统的深入，不断的重构?

最开初时，整体架构还是要有，但在具体实现时不要做过于复杂的设计，使其架构刚刚够用就可以了。最关键的是，不要为日后的扩展做太多的设计。
日后需求变更了，不要拿着代码就开始改，应当首先重构，再修改代码。
此外，我这里是一个体系的东西，还有好些东西，就像一本书需要一层一层拨开

6 楼 fangang 2014-01-15  

jackra 写道

感觉像是炒概念
有神马新鲜的地方？

需要你仔细体味，这里有几个要点：
1.小步快跑!=迭代开发，小步快跑周期更短，30分钟~1个小时一周期，更关注开发细节而不是研发管理；
2.强调的是重构，每次开发先重构，再开发新的功能，由此你不必一次搞定所有的设计与功能实现；
3.强调的是恰如其分的设计，恰如其分意味着它总是着眼当前，不偏不倚，从而保证质量的最优。

5 楼 jackra 2014-01-15  

感觉像是炒概念
有神马新鲜的地方？

4 楼 xiaozhi6156 2014-01-15  

是不是我可以这样子理解，刚开始的时候，就不必要做太多的架构的东西，而且随着系统的深入，不断的重构?

3 楼 fangang 2014-01-12  

我们还是相信缘分吧，缘分到了说不定你明天就碰到我了，未到则可能终其一生都不能见面，但又有神马关系呢，常登陆我的博客你就能学到很多东西。

2 楼 niva 2014-01-11  

写的真好，很清晰！
是如何把这些对象组装起来的呢？如果有完整的样例就好了。
楼主在什么公司啊，可以去投奔你么？

1 楼 w286332849 2014-01-09  

感谢LZ 收获很大