统计代码的小工具CodeLineCounter3.0

改进了以前的一个代码统计工具，主要是加入ui。这样操作时比较方便。

主界面如下

parser配置界面如下


以下是开发时的一些体会。

1 整体架构的进化
2 该写UT的地方还是要写的
3 对ResultItem的重构
4 UI的添加
5 参考其它的同类型程序
6 保持一个简单的核心概念模型

1 整体架构的进化

刚开始的时候考虑的比较简单,只是说想统计一下写的代码.
当时用的是.net开发的,一两个源文件就做完了.
但是后来不管怎么看都不灵活,主要是感到以下三个方面不太好.

1 对统计什么文件的设置不灵活,最早只能统计一个目录,可以从命令行读该目录,也可以跳过一些特殊的子目录,
如子目录里面包含test等等,但是这个是硬编码的.
2 只能统计java源文件.
3 统计的结果的展示比较单一,直接输出在一个文件里.

针对这几个缺点,考虑引入了以下概念.
1 引入CodeFileFilter来灵活的配置要统计的文件.
2 引入CodeFileParser来灵活的根据不同的文件来进行统计.
3 引入Reporter来报告结果.

后来在引入新的Filter和Reporter的时候,感到这个架构还是挺好用的.
尤其是在引入UI的时候,只需要引入新的UI Reporter就可以工作了.
经过一段时间的挣扎，CodeFileParser从一个用户可灵活插拔的接口（用户可以提供自定义实现）演化成一个默认实现，用户可以配置。


2 该写UT的地方还是要写的

一般我会对code写一些ut的,有的code貌似比较简单或者只有方法调用,我一般称之为架构性代码,这部分的ut做的
比较少,因为这种地方错了,马上程序运行就会出错.另一些逻辑比较多的地方的UT还是一定要加的.


3 对ResultItem的重构

本来对ResultItem的内容表现是在各处分散定义的,系统中有如下处在使用,在ResultItem的toString方法,
html的生成处以及UI的table显示.如果有改动的话(增加一个显示列或者删除一个显示列,或者显示列调整次序),
各个地方都要改动.
把这个对显示列的处理更新都放在ResultItem中.提供接口让想显示ResultItem的地方在这个基础上做自己的
显示逻辑.这样以后如果对显示列的列名啊,列数啊,值啊有改动,只要改ResultItem一个地方好了.

在TableModel的显示中变成了
@Override
public String getColumnName(int column) {
return ResultItem.getColumnName(column);
}

@Override
public int getColumnCount() {
return ResultItem.getColumnCount();
}

@Override
public Object getValueAt(int rowIndex, int columnIndex) {
ResultItem item = resultList.get(rowIndex);
return item.getColumn(columnIndex);
}
改到这个地方,突然发现这个重构很好,table的code又变漂亮了.
这个重构还顺带让我可以把ResultItem中的一些public方法改成private的.

对ResultItem的表示相关的值都是基于column用switch来判断的，这样当要加减一个列或者要
调整列的顺序的时候，有如下一些地方要改变。
共有多少个列，列名，列的Comparator,列的值。
很不舒服。
Refactor,增加一个集中的管理的地方，对一个列的相关内容进行集中管理，这样，当要修改的时候，
只要修改一个地方就好了。改后有点用code做配置的样子，虽然看着有点麻烦，但是前面的缺点也克服了。


4 UI的添加

这个程序在早的版本中是一个命令行程序,并不提供UI,因为最早的想法是自己用,而且如果给其他人用,
也一定是程序员用,而程序员改个配置文件之类的应该是简单的事情.
后来用的过程中,自己都觉得命令行麻烦,哎,还是加UI吧.
而且加UI的好处还有,让我时不时可以看到当前的成果,也好自我鼓励一下.可以想着添加一些高级的功能.

5 参考其它的同类型程序

开始的时候尽量不看其他的同类型程序,毕竟,自己想需求,模型,编程,调试本身是很有快乐的.
但是在做到差不多的时候,适当的参考一下其它的实现,有时候还是有一些启发的.
CodeLineCounter
竟然和我的程序的名字一样.比较简单,可以说是最小的功能了,有正则表达式支持.
GeroneSoft CodeCounterPro
界面比较好,功能也比较多,对comment的建模做的很细致,在这一级还有一个漂亮的模型.
BoomWorks 源代码统计工具
结合了测试用例和成本估计.

6 保持一个简单的核心概念模型
我的学习习惯比较偏好研究一些比较基本的概念。一旦概念掌握了，其他的就比较简单了。
编程时尽量维护一个便于理解的核心概念模型，对于自己的开发和维护而言，也是有很大益处的。

http://www.statsvn.org/