“千里之堤,毀于蟻穴”,很多軟件問題其實不是由重大的缺點引發(fā)的,反而是1些很細小的問題釀成的。下面羅列近期軟件開發(fā)進程中,我遇到的幾個程序編寫的細節(jié)問題案例。
案例1:
某軟件版本要實現從本地配置的目錄中掃描出文件并進行處理的功能,只有滿足特定前綴的文件才能被掃描出來。文件的前綴在配置文件中進行手動配置。在測試的進程中,我們發(fā)現在目錄中有很多滿足配置前綴的文件,但1個都沒有被掃描出來。
問題到底出在哪里呢?為了查找問題緣由,我們在代碼中添加了很多的調試日志,最后發(fā)現讀入的前綴配置值后面多了1個“*”。我們又查看了配置文件,發(fā)現在手動添加配置值的時候,在前綴的后面加了1個“*”,當作通配符使用。但程序其實不需要加通配符,只要將前綴寫上就能夠了。
假定配置項Prefix表示前綴,那末修改之前的示例以下:
Prefix=prefix*
修改以后的示例以下:
Prefix=prefix
1個小小的“*”,就使得全部程序的功能異常,能說細節(jié)不重要嗎?
案例2:
某軟件版本要從配置文件中讀取路徑值來拼裝文件的寄存位置。在測試的進程中,程序出現異常,打印出的日志顯示文件路徑不存在。我們查看了本地的磁盤,該路徑是存在的。那為何程序找不到這個路徑呢?
程序中的路徑來源于兩個部份,1部份是配置文件中某個配置項(假定為FilePath)的值,另外一部份是程序本身生成的。為了查找問題緣由,我們一樣在代碼中添加了詳細的調試日志,發(fā)現最后拼裝出的路徑多了1條斜杠,形如“D:zhoumailwang”。
查看相干代碼和配置項,原來在配置項的后面已添加了1條斜杠,而在程序最后拼裝路徑的時候,又在中間添加了1條斜杠。即在“D:zhoumail”和“wang”之間添加了“”。如此處理,程序能夠找到這個“奇怪”的路徑才怪了!
案例3:
在查看某軟件版本生成的日志的進程中,發(fā)現有1條日志打印出的變量值非常的奇怪。查找該條日志對應的代碼,情勢以下:
WriteLog(Log_Info, "Name=%d, Age=%d", Name, Age);
該條日志要打印出變量Name和Age的值,但在定義變量的時候,Name是字符型數組,而Age是整型。但代碼“Name=%d, Age=%d”所示,兩個變量都以整型(%d)的情勢來打印,能夠正常嗎?正確的情勢是“Name=%s, Age=%d”。
這個問題基本不會影響程序的正常流程,由于它是出現在日志當中的。但我們也不能置之不理,細節(jié)問題不處理好,積累起來就會出現大的問題。
案例4:
在運行某軟件版本http://www.jyygyx.com/db/腳本(sql文件)的時候,總是報語法毛病。查看對應的SQL語句,發(fā)現在初始化某1字符型變量的時候,使用了以下語句:
select @namestr = "Zhou"
大家或許注意到了,在SQL語法中,字符串是用單引號來標志的,而不是雙引號。這個語法是與C語言有區(qū)分的。但很多開發(fā)人員熟習了C語言的那1套語法規(guī)則,因而在http://www.jyygyx.com/db/腳本中,也用雙引號在初始化字符型變量。
正確的SQL語句以下:
select @namestr = 'Zhou'
以上4個案例,相信可能很多人都遇到過。那末,我們如何避免以上細節(jié)問題的出現呢?
第1,在編寫程序的時候,我們1定要全神貫注。我看很多人喜歡把手機放在手邊,時不時地低頭看1下,也不知道每天為何總有那末多消息。這樣做會致使精力的分散,寫出來的程序自然不會讓人很放心,出現bug也是很正常的了。
第2,在寫完程序以后,我們1定要多檢查幾遍,不要認為功能正常就沒問題了。大家不要嫌麻煩,盡可能把每行代碼都看1下,以發(fā)現1些容易被疏忽的問題。“謹慎駛得萬年船”,只有我們認真對待每行程序,程序才會“對得起”我們。
第3,在寫好程序以后,不要急著提交,讓同事對代碼進行走查。代碼走查也是同行評審的1種,其目的是提高代碼的質量。1個人的視野有限,很多問題都發(fā)現不了。或許你沒有發(fā)現的問題,同事1眼就看到了。軟件的質量是要靠大家共同努力來提高的。
細節(jié)決定成敗,這個道理在軟件開發(fā)中也是成立的。只有不斷地實踐、不斷地總結,我們才能夠提高代碼的質量,讓細節(jié)問題無處藏身。
(本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5,微信號:245924426,歡迎關注!)