周一到周三，我的领导亲自操刀，完成了一项小小的功能。
功能虽小，但从构思到实现，再到稳定运行，几乎包含了软件开发的全过程。
这个过程完美的展示了 编写一段优秀的代码 需要考虑多少东西，我记下来给大家分享一下。
需求很简单：
分析各类日志文件（如：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平台上发现正则表达式解析有问题，不能过滤掉无用的行。
再次修正：
这次修正主要解决跨平台兼容性问题。
验收测试和稳定性测试：
在个平台上部署，并长时间运行。
打包发布：
预编译出常见平台的二进制代码，
编写相关安装和使用说明。
----
软件开发，无论功能大小，其实都需要这些过程，
只是对于小功能，每个阶段的切换很快（有时候只是脑海里的想法而已），
但心里要清楚：
有时候想省事儿，可能反而会更加费事儿，比如需求分析的时候搞不清楚就开始做，只会引起很多的返工。
而另外一些时候，卡在一个地方太久，想不清楚，可能需要先试着向前推进，很多问题就会“迎刃而解”。
山穷水复疑无路，柳暗花明又一村，
这是在软件开发过程中经常能够体会到得心路历程。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jinxfei/archive/2009/05/27/4221623.aspx