问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

时间:2022-05-20 15:41:00

不能说所有的bug都是纸老虎,但往往那种看似很奇葩的bug,导致的原因确实很简单,烦了你一段时间,找到真相又让你忍不住一笑。什么是奇葩的bug呢。我的定义是:代码逻辑都一样,但在A处是好的,到了B处就不行或者同类的ABC都是好的,D却不行了的bug。而最终,问题确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方。

本地都是ok的,服务器还是不行,怪我咯

case1:本地工程改好,推倒服务器上,但一会儿,测试妹妹又叫了,“还是不行,你再看看”。顿时眉头一皱,怎么可能,自己又run一遍,妥妥的啊。然后又到服务器上push下来,跑一遍,也ok啊。唯独ccnet 持续集成编译不能通过。抓耳挠腮的想了半天。发现刚刚运行的都是debug版,而ccnet跑到是Release版本。而正是因为Debug写了些配置,Release却没有写所以错了。

小结:不要从一开始就忙错了,除了debug,Release。git上面还有master,release,prelease,newFunction等诸多版本。这要是改错了可能回导致更大的麻烦。

case2: 按照客户需求改好了功能,放到云服务器上之前,我都会在本地的iis发布确认通过。但有一次突然发现每次访问都要登录认证。就如下图:

问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

明明是设置了可匿名访问,也赋予了IUSR_xxxx ,Everone,各种权限,但就是不行。本地是iis7,服务器上是iis6,这会有什么差别?但是同目录的其他网站都是ok的。我照着正常的网站配置,也不行,重新部署也没有解决。然后各种搜罗,各种看帖,心想肯定还是和权限有关,也许是某个文件,也许是webconfig的配置,但试了发现还是无效。深更半夜,默默和屏幕对视,窗外,秋风乍起,屋里,室友已经熟睡。

问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

突然眼前一亮,有个博客说可能是IUSR_xxx账户没有AD权限,在匿名用户的地方需要设置一个有权限的账户。我换了成xxxx/Adminstrator ,果然好了。但为什么是这样,别的网站的匿名用户是IUSR_xxx都ok,这样会不会有什么问题。现象是解决了,但真正导致的问题还没有找到,或许是某个程序,或许是某个文件。还要继续跟进。

小结:表面上相似的个体,还是有各自的差异性。但这个问题只是解决了现象,没有解决本质。

case3:这个问题真真的是奇葩,同事问我说,他webservice调用不了了。上午还好好的,下午就报407代理错误。但又是那句老话:“我其他的服务都能调用啊,在别的电脑上也能调用,就这台电脑突然不行了” ,我和他测来测去,api本身没有问题,网络没有问题,电脑没有问题,代码也没有问题,因为根本没有进来。那问题在哪?然后他老婆(对,他和他老婆坐一起)无意中在VS中点开了app.config。然后这个文件显示被自动修改了,然后程序就通了。类似问题我也遇到过,我有一个程序是使用 XDocument.Save方法每次去覆盖一个文件,但老是没有成功覆盖,即使vs提示:“文件已被修改,是否重新加载当前文件” 我点确定,还是没有改掉,但我把文件内容删掉。却又可以成功覆盖。然后同事建议我换成 File.WriteAllText方法,就好了。

小结:大家有遇到过么,xml文件没有成功修改。或者是经常变动的文件不适合用xml持久化?

EF开的玩笑

事情是这样,为了让内容在表格中较好的显示,我把内容较长的截取了一下,但是发现,用到的地方都被改变了,但一看数据库又没有改变。

问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)
   foreach (var note in notes)
{
var str = CommonHelper.StripHTML(note.Content);
if (str.Length > 15)
{
note.Content = str.Substring(0, 12) + "...";
}
}
问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

但是并未保存。但是再捞出一条时,内容却变化了。

    raw = _respository.GetNoteById(id);

问题(bug)确实不在代码逻辑上面,往往是配置、权限或者业务逻辑之外的地方(转)

但数据库没变变化。

然后重新启动,先访问编辑页面,数据又是正常的,明显受到了前面方法的影响。难道数据被缓存了?后来发现,因为自作聪明搞了个单例,仓库内部的db=xxDB.GetInstance()。结果因为这两个页面都是一个上下文。数据被缓存了下来,导致查询的对象不是来自数据库。这个时候如果保存一下,其他的被缩短的内容也都会被保存到数据库中。而最简单的办法就是 db=new dbcontext();

小结:这纯粹是自己不了解EF的机制导致的麻烦,弄巧成拙。

ckeditor 也不听话

同事做个功能,异步加载一个编辑框,发现有时候能加载成功,有时候不能。有的页面一直可以,有的页面一直不行。

 <textarea class="" name="Content" id="Content">
     CKEDITOR.replace('Content',
{
toolbar: ...
});

其实,对于ckeditor,replace后面的这个参数id也可以,name也可以。但那次发现他的那两个参数不一样,改成一样的,就都加载成功了。可能是有的页面有干扰吧。

还有些“神奇现象”,说不出原委,也就不提了。但往往这些bugs会耗费掉我们很多时间。能找到原因的问题,绝大部分会有解决办法。找不到原因的问题,才是不好解决的问题。有时候即使解决了现象,但未必解决了问题的引发的原因,所以我习惯将这些事情都记录下来,出现一次,可能就会出现第二次。此文,献给那些我们调bug的碎片时光。

http://www.cnblogs.com/stoneniqiu/p/4925303.html