单元测试和代码覆盖工具对于提高代码质量确实是很有帮助的，但是不能迷信，详细的内容已经有人代劳了：

追求代码质量: 不要被覆盖报告所迷惑

昨天晚上在构建我自己想做的东西的时候，本来没有打算写单元测试的，但是后来看看时间，做新的功能似乎不够，就写了写单元测试，结果发现代码质量不是一般的差，几个我认为肯定没有问题的地方也出问题了。以后的代码一定要坚持写单元测试，而且今天晚上回去就要把代码覆盖的工具也用上，可能是emma或者Cobertura。

今天Bruce问我spring怎么样，我的感觉主要是：

• 可以用配置文件组装系统，使得系统很灵活，可以在不修改原有代码的情况下扩充功能或者替换某个实现
• 可以使用声明式事务
• 使用使用spring提供的模板简化代码
• 可以使用spring提供的其它很多功能简化代码
• 可以使用AOP

但是：Spring不是必须的。
对于小项目，引入spring可能反到增加不必要的复杂性，毕竟spring也是需要很多配置的，有时候就没有一个new来得简单，而且使用spring后很多错误要到运行的时候才能发现，而修改配置已经来不及了，只能重启 web服务器。
（在spring的配置太多的时候，启动好像很慢，这个是因为要预先初始化很多类并组装好）

但是总体上感觉spring是个好东西，在以后的项目中要尽量使用。

最后推荐：疑惑：为什么要用Spring？以及简化Spring

bruce说我的那个得到GMT时间的
代码是错误的，和他讨论了很长时间，后来发现果然是我的理论方面有问题，就java.util.Date类的定义而言，它本来就是当前的GMT时间相对于
1970年1月1日的GMT时间的long值，但是如果使用System.out.println()等方法打印出其内容的时候，也就是使用
Date.toString方法的时候，我们看到的是经过时区修正的结果，这个看看java.util.Date的实现就可以知道：

    public String toString() {
	DateFormat formatter = null;
	if (simpleFormatter != null) {
	    formatter = (DateFormat)simpleFormatter.get();
	}
	if (formatter == null) {
	    /* No cache yet, or cached formatter GC'd */
	    formatter = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
					     Locale.US);
	    simpleFormatter = new SoftReference(formatter);
	}
        synchronized (formatter) {
            formatter.setTimeZone(TimeZone.getDefault());
            return formatter.format(this);
        }
    }

从代码我们可以看到是使用时区格式化的结果（JDK5的代码和这个不同）。
问题是：当我们将这个GMT的Date值转换到java.sql.Date或者java.sql.Timestamp存到数据库里面以后，数据库里面的值
是我们的本地时间而不是GMT时间，因此，如果你需要数据库存储GMT时间的时候，还是需要使用我的那个方法进行转换。至于为什么要存储GMT时间，这个
是有跨时区应用的时候要考虑的问题，例如一个系统中国的用户和美国的用户同时使用，否则时间会很混乱。

本来以为得到GMT时间很简单，通过Calendar 
date = Calendar.getInstance(TimeZone.getTimeZone(“GMT”));然后
date.getTime()就是，但是实际的结果不是，要得到GMT时间还是需要转换下的，以下是得到当前的GMT时间：
    public static Date getGMTDate ()
    {
        Calendar calendar = Calendar.getInstance();
        int offset = calendar.get(Calendar.ZONE_OFFSET)/3600000 +
               
calendar.get(Calendar.DST_OFFSET)/3600000;
        calendar.add(Calendar.HOUR,-offset);
        return calendar.getTime();
    }