週一到週三，我的領導親自操刀，完成了一項小小的功能。
功能雖小，但從構思到實現，再到穩定運行，幾乎包含了軟件開發的全過程。
這個過程完美的展示了 編寫一段優秀的代碼 需要考慮多少東西，我記下來給大家分享一下。
需求很簡單：
分析各類日誌文件（如：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