程式編寫中的細節問題

“千里之堤， 毀於蟻穴”， 很多軟體問題其實不是由重大的缺點引發的， 反而是1些很細小的問題釀成的。 下面羅列近期軟體發展進程中， 我遇到的幾個程式編寫的細節問題案例。

案例1：

某軟體版本要實現從本地配置的目錄中掃描出檔並進行處理的功能， 只有滿足特定首碼的檔才能被掃描出來。 檔的首碼在設定檔中進行手動配置。 在測試的進程中， 我們發現在目錄中有很多滿足配置首碼的檔， 但1個都沒有被掃描出來。

問題到底出在哪裡呢？為了查找問題緣由， 我們在代碼中添加了很多的調試日誌，

最後發現讀入的首碼配置值後面多了1個“*”。 我們又查看了設定檔， 發現在手動添加配置值的時候， 在首碼的後面加了1個“*”， 當作萬用字元使用。 但程式其實不需要加萬用字元， 只要將首碼寫上就能夠了。

假定配置項Prefix表示首碼， 那末修改之前的示例以下：

Prefix=prefix*

修改以後的示例以下：

Prefix=prefix

1個小小的“*”， 就使得全部程式的功能異常， 能說細節不重要嗎？

案例2：

某軟體版本要從設定檔中讀取路徑值來拼裝檔的寄存位置。 在測試的進程中， 程式出現異常， 列印出的日誌顯示檔路徑不存在。 我們查看了本地的磁片， 該路徑是存在的。 那為何程式找不到這個路徑呢？

程式中的路徑來源於兩個部份， 1部份是設定檔中某個配置項(假定為FilePath)的值， 另外一部份是程式本身生成的。

為了查找問題緣由， 我們一樣在代碼中添加了詳細的調試日誌， 發現最後拼裝出的路徑多了1條斜杠， 形如“D:zhoumailwang”。

查看相干代碼和配置項， 原來在配置項的後面已添加了1條斜杠， 而在程式最後拼裝路徑的時候， 又在中間添加了1條斜杠。 即在“D:zhoumail”和“wang”之間添加了“”。 如此處理， 程式能夠找到這個“奇怪”的路徑才怪了！

案例3：

在查看某軟體版本生成的日誌的進程中， 發現有1條日誌列印出的變數值非常的奇怪。 查找該條日誌對應的代碼， 情勢以下：

WriteLog(Log_Info, "Name=%d, Age=%d", Name, Age);

該條日誌要列印出變數Name和Age的值， 但在定義變數的時候， Name是字元型陣列， 而Age是整型。 但代碼“Name=%d, Age=%d”所示， 兩個變數都以整型(%d)的情勢來列印， 能夠正常嗎？正確的情勢是“Name=%s, Age=%d”。

這個問題基本不會影響程式的正常流程，

由於它是出現在日誌當中的。 但我們也不能置之不理， 細節問題不處理好， 積累起來就會出現大的問題。

案例4：

在運行某軟體版本http://www.wfuyu.com/db/腳本(sql檔)的時候， 總是報語法毛病。 查看對應的SQL語句， 發現在初始化某1字元型變數的時候， 使用了以下語句：

select @namestr = "Zhou"

大家或許注意到了， 在SQL語法中， 字串是用單引號來標誌的， 而不是雙引號。 這個語法是與C語言有區分的。 但很多開發人員熟習了C語言的那1套語法規則， 因而在http://www.wfuyu.com/db/腳本中， 也用雙引號在初始化字元型變數。

正確的SQL語句以下：

select @namestr = 'Zhou'

以上4個案例， 相信可能很多人都遇到過。 那末， 我們如何避免以上細節問題的出現呢？

第1， 在編寫程式的時候， 我們1定要全神貫注。 我看很多人喜歡把手機放在手邊，

時不時地低頭看1下， 也不知道每天為何總有那末多消息。 這樣做會致使精力的分散， 寫出來的程式自然不會讓人很放心， 出現bug也是很正常的了。

第2， 在寫完程式以後， 我們1定要多檢查幾遍， 不要認為功能正常就沒問題了。 大家不要嫌麻煩， 盡可能把每行代碼都看1下， 以發現1些容易被疏忽的問題。 “謹慎駛得萬年船”， 只有我們認真對待每行程式， 程式才會“對得起”我們。

第3， 在寫好程式以後， 不要急著提交， 讓同事對代碼進行走查。 代碼走查也是同行評審的1種， 其目的是提高代碼的品質。 1個人的視野有限， 很多問題都發現不了。 或許你沒有發現的問題， 同事1眼就看到了。 軟體的品質是要靠大家共同努力來提高的。

細節決定成敗， 這個道理在軟體發展中也是成立的。 只有不斷地實踐、不斷地總結， 我們才能夠提高代碼的品質， 讓細節問題無處藏身。