一个小项目的完整开发过程

周一到周三，我的领导亲自操刀，完成了一项小小的功能。

功能虽小，但从构思到实现，再到稳定运行，几乎包含了软件开发的全过程。

这个过程完美的展示了编写一段优秀的代码需要考虑多少东西，我记下来给大家分享一下。

需求很简单：

分析各类日志文件（如：Oracle的错误日志）的内容，并将其中符合条件的行转发到Syslog。

需求分析：

读取日志并过滤内容比较简单，这个需求的关键点在于：必须考虑时效性和性能。

时效性，通常日志是不断增长的，要求程序尽快分析新增日志。

性能，要求程序能够对日志做增量分析，以免去不必要的I/O开销。

制定方案：

根据需求分析得到的功能需求和非功能需求，我们一致认为，需要一种手段来实时获取文件中的新增内容。

在Unix/Linux上，tail指令可以实现这种功能。

我们调查tail指令后发现一个严重的问题：

tail无法处理日志的切换。

这一问题否决了我们使用unix已有指令写shell的想法，于是决定自己编写一个类似tail的小工具。

在实现方案上，可以采用C或者Java两种方式，基于如下考虑：

1、日志在Unix/Linux上的情况占80%以上

2、目标主机上不一定具备java环境

3、要求对目标主机的资源消耗尽量小

因此，决定采用C来做实现，由于项目组人员以JAVA为主，所以领导亲自上阵了。

技术预演：

技术预演是为了验证方案的可行性，如果方案的设想因为技术原因无法实现，则需要修改方案。

这个小功能的技术预演主要包括：

1、分析tail源码，了解tail实时获取文件增量的原理。

2、调查C中如何发送Syslog

实现：

基本功能：

领导最初认为这个功能很简单，不会超过30行代码，而基本功能也确实很简单。

功能增强：

支持打开多个文件，

支持日志切换，

支持使用正则表达式对行进行过滤，

支持通过命令行参数制定Syslog输出的Severity和Facility

测试：

将程序编译后挂到实际环境中测试，很快发现一些问题，

比如：

对参数的异常情况考虑不足

文件切换有两种模式，需要兼容（一种inode变，一种不变）

需要检查目标文件是否存在、是否为普通文本文件（二进制文件无法处理、目录也可以当做文件打开）

程序修正：

解决测试中遇到的问题，

增加文件类型判断、兼容文件切换模式、参数错误时输出Usage等

除此之外，程序还进一步考虑了异常情况下（如：进程被kill）对资源的释放等。

再测试：

在HP-UX平台上，功能测试基本没发现问题，

但迁移到Linux平台上发现正则表达式解析有问题，不能过滤掉无用的行。

再次修正：

这次修正主要解决跨平台兼容性问题。

最终程序超过300行，超过最初预期10倍。

验收测试和稳定性测试：

在各平台上部署，并长时间运行。

打包发布：

预编译出常见平台的二进制代码，

编写相关安装和使用说明。

软件开发，无论功能大小，其实都需要这些过程，

只是对于小功能，每个阶段的切换很快（有时候只是脑海里的想法而已），

但心里要清楚：

有时候想省事儿，可能反而会更加费事儿，比如需求分析的时候搞不清楚就开始做，只会引起很多的返工。

而另外一些时候，卡在一个地方太久，想不清楚，可能需要先试着向前推进，很多问题就会“迎刃而解”。