“千里之堤，毁于蚁穴”，很多软件问题其实不是由重大的缺点引发的，反而是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眼就看到了。软件的质量是要靠大家共同努力来提高的。
细节决定成败，这个道理在软件开发中也是成立的。只有不断地实践、不断地总结，我们才能够提高代码的质量，让细节问题无处藏身。
(本人微博：http://weibo.com/zhouzxi?topnav=1&wvr=5，微信号：245924426，欢迎关注！)