64 个解决方案
#1
需求总是调整，刚写完的模块又要修改
所以之前需求一定要沟通好，框架模块尽量松耦合，随时适应变化
所以之前需求一定要沟通好，框架模块尽量松耦合，随时适应变化
#2
回想起这个bug，仍然让我有些痛苦。作为一个程序员，在发现bug时，你学会了首先在自己代码中找问题，或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。
这是我遭遇一个硬件bug的故事。
抛开别的不说，我曾为《Crash Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情，但我一直回来处理这个bug——几天内每天几个小时。这个bug实在烦人。
这个bug的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。
过了一段时间，我们在Sony的制作人Connie Booth慌了。我们显然不能带着这个bug发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。
在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的bug所在。
在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？
你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现bug事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。
长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码——就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载/保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载/保存屏幕并且请求保存，然后写入卡中。
我最终以一个带有这个bug的很少量的代码结束——但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的Crash的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。
在那时——估计是凌晨3点——一个想法蹦了出来。读写（I/O）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。
时钟让不直接连接到CPU的硬件设备和cpu运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。
如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将PS1上的可编程计时器设置到了1kHz（1000跳每秒）。这是比较快了，当PS1启动的时候，默认状态大概是100Hz。因此，大多数游戏将他们的计时器设置为100Hz。
这个游戏的带头（和除我外的唯一）开发者Andy，将计时器设置为1kHz，使得Crash的动作计算更加准确。Andy喜欢矫枉过正，如果我们要模拟重力，我们应该尽可能的提高精度！
然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？
我将计时器代码注释掉。然后我就无法复原这个bug了。但是这并不表示bug被修复了，这个问题是随机发生的。万一我只是运气好呢？
几天过去了，我还是在玩我的测试程序。Bug没有再出现。我回到全部的Crash代码中，修改了加载/保存代码，在访问存储卡之前将可编程计时器重置为默认设置（100Hz），之后设置回1kHz。从此之后没有发现问题再次出现。
但是…为什么？
我重新回到测试程序上，试着检测当计时器设置为1kHz时出现的那些错误的模式。终于，我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载/保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。“等下，怎么回事？喂，再来一次！”
一旦我发现了这两件事是联系着的，就很容易重现bug：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件bug。
我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知：“不可能，这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。
那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：“我给你一个30行的测试程序，让你在动手柄的时候能够出现这问题。”他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是Sony很重要的开发者，他会试的。
第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。
我还是没有完全搞清楚问题到底在哪，但是我的印象中，从Sony总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。
但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在1kHz的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。
这是我全部编程生涯中，唯一一次因为量子力学debug的问题。
来自http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
这是我遭遇一个硬件bug的故事。
抛开别的不说，我曾为《Crash Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情，但我一直回来处理这个bug——几天内每天几个小时。这个bug实在烦人。
这个bug的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。
过了一段时间，我们在Sony的制作人Connie Booth慌了。我们显然不能带着这个bug发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。
在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的bug所在。
在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？
你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现bug事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。
长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码——就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载/保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载/保存屏幕并且请求保存，然后写入卡中。
我最终以一个带有这个bug的很少量的代码结束——但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的Crash的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。
在那时——估计是凌晨3点——一个想法蹦了出来。读写（I/O）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。
时钟让不直接连接到CPU的硬件设备和cpu运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。
如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将PS1上的可编程计时器设置到了1kHz（1000跳每秒）。这是比较快了，当PS1启动的时候，默认状态大概是100Hz。因此，大多数游戏将他们的计时器设置为100Hz。
这个游戏的带头（和除我外的唯一）开发者Andy，将计时器设置为1kHz，使得Crash的动作计算更加准确。Andy喜欢矫枉过正，如果我们要模拟重力，我们应该尽可能的提高精度！
然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？
我将计时器代码注释掉。然后我就无法复原这个bug了。但是这并不表示bug被修复了，这个问题是随机发生的。万一我只是运气好呢？
几天过去了，我还是在玩我的测试程序。Bug没有再出现。我回到全部的Crash代码中，修改了加载/保存代码，在访问存储卡之前将可编程计时器重置为默认设置（100Hz），之后设置回1kHz。从此之后没有发现问题再次出现。
但是…为什么？
我重新回到测试程序上，试着检测当计时器设置为1kHz时出现的那些错误的模式。终于，我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载/保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。“等下，怎么回事？喂，再来一次！”
一旦我发现了这两件事是联系着的，就很容易重现bug：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件bug。
我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知：“不可能，这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。
那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：“我给你一个30行的测试程序，让你在动手柄的时候能够出现这问题。”他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是Sony很重要的开发者，他会试的。
第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。
我还是没有完全搞清楚问题到底在哪，但是我的印象中，从Sony总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。
但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在1kHz的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。
这是我全部编程生涯中，唯一一次因为量子力学debug的问题。
来自http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
#3
需求变更，这是遇到的最令人无解的问题。
#4
房价问题。。。。。。。。。。。。写死了编码都买不起房子。。。。。这问题太蛋疼了
#5
写人生代码最难
经过20多年的学习、熏陶、训练。。。等到了工作时了，发现这些东西竟然都全无用武之地！首先是，应该的不如领导的一句话，讲理者被喻为情商低下（因为当你碰壁无数时终能发现：和领导不能讲理，和长辈不能讲理，和流氓不能讲理，。。。）做的再多，只要不合领导心思就全部为0。。。失败多了会让人懒惰，勤快人活该受罪。。。
--------这些 bug 你发现了吗？改了吗？
#6
需求变化是经常有的事。
在之前的公司，我同事用asp.net开发完一个项目，结果客户说不好用，说没象C/S那样可以方便使用，结果老板又重新叫我和那个同事用sliverlight开发同样一套出来，客户还是说有一点上问题而不用，期间我至少参与开发两个月。
直到我离开公司的那一天，那个项目都没得上线。
不是技术有多牛，就能推动项目上线，客户是否配合？也是项目能否上线的原因之一，项目不上线，钱是永远不能回收的，钱收不回对于技术公司来说打击最大，有的甚至因此而倒下。
在之前的公司，我同事用asp.net开发完一个项目，结果客户说不好用，说没象C/S那样可以方便使用，结果老板又重新叫我和那个同事用sliverlight开发同样一套出来，客户还是说有一点上问题而不用，期间我至少参与开发两个月。
直到我离开公司的那一天，那个项目都没得上线。
不是技术有多牛，就能推动项目上线，客户是否配合？也是项目能否上线的原因之一，项目不上线，钱是永远不能回收的，钱收不回对于技术公司来说打击最大，有的甚至因此而倒下。
#7
一个工控程序，电梯的调度算法，一直和自己的程序运行的不一致，最后发现是硬件问题！
#8
硬件bug非常难发现啊
#9
楼上的基本都不是BUG
#10
做到一半 客户该需求
#11
X总，这个要加钱，哪有白改的，做需求的时候你可是都签了字同意的！
#12
问题的根本是，不合领导的心思全部为零，领导否决你的原因是不是引导往你更优的方向走呢，如果不是，你可以与他据理力争
#13
看来客户需求变更才是项目最大的难题，而不是技术
#14
没钱
#15
3D场景的A*寻路
#16
代码不是问题，问题是人
#17
微软的所有UI平台都支持MVC设计模式,
多提供一个SL版而已,如果曾经做过SL项目,几乎不需要编写代码,
你们居然又重新开发一遍,重复劳动,又耽误时间
#18
这是软件系统的4个基本问题:
1.问题域的复杂性:
系统的复杂性远远超出了程序员的知识范畴;
2.交流问题
技术专家和领域专家知识的断层影响了交流;
3.需求的变化
系统成分的从最易变化的到最稳定的依次是:功能,接口,数据,对象(域);
4.复用:
软件生产各种工序,分析级,设计级,实现级各个级别上的复用
现代OOAD方法在以上几个方面提供了强有力的支持
#19
不符合MVC思想，而且给程序的扩展维护，人员的分工合作带来很大的困难，美工只懂HTML代码，而大量的java代码在页面，显而易见！程序的可读性差，你自己想想，大量的代码全部混合在页面看代码有多费力
#20
这个人生bug你身上还真不少：和领导讲理不是找死吗？
你要讲的不是谈待遇，而是你有多大为公司创造价值的能力！
先体现你的能力吧---通过你所创造的价值，待遇问题---领导不是瞎子。。。
#21
每一个新问题都是最难的
#22
买不起130M的房子,买不起宝马530Li
这目前就是我最难的了..
这目前就是我最难的了..
#23
总会有的，钱多到一定境界你就感受不到钱的存在了
#24
#25
价值分2种，有形的，可用金钱计算的；无形的，你的说话做事做人是不是让周围的人觉得舒服可人
#26
你要表达的观点是……
#27
最难的莫过于，我想搞oracle，领导却让我把oracle代码改成mysql
#28
房价问题。。。。。。。。。。。。写死了编码都买不起房子。。。。。这问题太蛋疼了
#29
遇到了喜欢的车没钱买怎么办
#30
#31
一般难的复杂的问题 耗时特别长的都评估下值不值得做，实际上很多难的问题都推掉了
当然这辈子最难解决的问题就是---没钱
当然这辈子最难解决的问题就是---没钱
#32
如何才能搞到妹子。。。。
#33
#34
目前来说，碰到的最难的是这个： [木星文]B2C3DB8BC88C5F0287C4C05C2734455C6DEEFCF3F2B758076635E9A90AB64A36B6097AD9D0D6031AC5DED8B76ACCB91FD3C2B5203F16013C3E29767F62A6A978158711A0EC692073DF63D24672CEF85A2A30F389B100CA9E3CC8A2F4295DC49210F093C0C1260E5234FF7012388D8E35D1C238DA7935001B4A4F0875FDAF2EBE8051281D5682E8EF41670CFBA4C167E7AF88C4B23B0AC0715E320F45D7253859
木星文翻译请通过我博客上的地址翻译哈
木星文翻译请通过我博客上的地址翻译哈
#35
我是写给有缘人看的，你只管安心做个码农就得了
#36
超级赞的经验~~~~~
#37
前端视频获取码流后（H264标准码流），加入私有头写入录像文件，但是录像文件是快放的；码流解析的时候发现I帧和P帧的时间戳都有问题；但是重获取码流到写入文件，数据都是完全正确的；搞了很久，最后发现该码流必须用二进制文件存储文件，普通方式存储就好出现跳帧问题
#38
自己翻译的，翻译得不好请原谅
So, while studying electrical engineering at school, we had a class where you were supposed do a project related to embedded systems. Me and two classmates really enjoyed the course and decided to build an autonomous RC helicopter. We attached a MCU to a helicopter to control the servos with some input from an accelerometer. The project was a little to ambitious for the 3 month class, especially since we were all new to embedded systems. But it was very fun, and we worked hard, so things were moving along fine.
在我还在学校学习电子工程的时候，我们有一堂课是学习嵌入式系统工程，我还有我的两个同学非常喜欢这堂课，而且我们准备自己动手造一个遥控直升机。我们绑了一块写入了加速计指令的MCU芯片在直升机上来控制舵机〔自动驾驶仪附件〕。这个工程对于3个月时间的课程来说有点野心太大了，而且我们都还只是嵌入式系统的新手。但是我们非常认真也非常努力，所以我们刚开始做的还不错。
One late evening we sort of had all the different parts of the system working and were ready to mount it all on the helicopter to start doing trial flights. The only problem was that once we started the system, the servos wen't bananas every now and then. We went over all code several times, removed more and more pieces the system but still couldn't get rid of this behavior.
有一天深夜，我们仍然在调试中。差不多把系统每一个部分都调试到了理想水平而且我们准备开始第一次测试飞行。唯一的问题是，当我们启动系统的时候，直升机总是会时不时的出现失去平衡，我们把代码测试了好几遍，删除了越来越多的代码来确定问题出现在哪里，但是我们还是没有把这个失衡的问题解决。
After a long night of debugging where less and less things were making sense we didn't really know what to do. One of the team members got so tired of everything that he leaned back, put his shoes up on the table and closed his eyes for a while. Suddenly, the bug didn't appear any more. Tired and out of ideas we started joking around about his shoes maybe being a magical cure for the bug. He played along and started taking his shoes up an down from the table. The freaky thing was that the bug actually wouldn't appear when his shoes were on the table, but did appear when they weren't. After a while we actually started considering that there could be a correlation. Half laughing, half crying of exhaustion we actually did 10-20 runs with feet on table / feet off table and the bug happened exclusively when his feet was off the table. I think this probably was one of my most confusing moments in life, at least related to technology.
经过一夜不眠的调试，我们开始发觉调试代码越来越没有意义，不知道该做什么，我们团队中的一员开始对我们的调试工作感到厌倦了，干脆就倾斜着身子，脚搭桌子上闭着眼镜休息。突然，我们发现问题没有再出现，又困又累的我们感到十分惊喜，开始开玩笑说也许他的鞋是这个bug的克星，于是我们开始玩性大发，测试在鞋没有在桌上和在桌上两种情况下的不同测试结果。非常诡异的事情出现了：当我们把鞋放桌上的时候bug就消失不见了，当把鞋拿开的时候，bug又出现了！过了一会我们才开始仔细考虑这两者之间的关联，我们哭笑不得，在测试了10到20次“鞋在桌上和鞋不在桌上”的测试以后，也许这件事是我一生中经历过最困惑的事情，但是最后我们还是靠科技解决了这个问题。
That's when it hit us. Common ground! Turns out we forgot to connect ground between two parts of the system which led to communication between them being extremely unstable and sensitive to pretty much anything. When my teammate put his feet on the table, he connected ground between the two parts of the system with his shoe and the table where the other part of the system was located. Even though this connection was probably extremely weak, it was enough to make make the communication a little more stable. As soon as we realized what happened, we connected the missing wire and everything was running perfectly (well, at least in regards to that problem).
大地！从我的脑海中突然蹦出来。原来我们忘了将系统中的两个部分接地，导致两个系统之间的联系非常不稳定而且几乎对任何东西都十分敏感。所以当我的队友把他的脚搭在桌子上的时候，他用他的鞋把系统的两个部分接地了。即使这种通信非常微弱，也足够让这两部分的通信更稳定了。当我们明白是怎么回事的时候，我们补充了我们之前忘了添加的电线，结果一切都正常了。
来自
http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
So, while studying electrical engineering at school, we had a class where you were supposed do a project related to embedded systems. Me and two classmates really enjoyed the course and decided to build an autonomous RC helicopter. We attached a MCU to a helicopter to control the servos with some input from an accelerometer. The project was a little to ambitious for the 3 month class, especially since we were all new to embedded systems. But it was very fun, and we worked hard, so things were moving along fine.
在我还在学校学习电子工程的时候，我们有一堂课是学习嵌入式系统工程，我还有我的两个同学非常喜欢这堂课，而且我们准备自己动手造一个遥控直升机。我们绑了一块写入了加速计指令的MCU芯片在直升机上来控制舵机〔自动驾驶仪附件〕。这个工程对于3个月时间的课程来说有点野心太大了，而且我们都还只是嵌入式系统的新手。但是我们非常认真也非常努力，所以我们刚开始做的还不错。
One late evening we sort of had all the different parts of the system working and were ready to mount it all on the helicopter to start doing trial flights. The only problem was that once we started the system, the servos wen't bananas every now and then. We went over all code several times, removed more and more pieces the system but still couldn't get rid of this behavior.
有一天深夜，我们仍然在调试中。差不多把系统每一个部分都调试到了理想水平而且我们准备开始第一次测试飞行。唯一的问题是，当我们启动系统的时候，直升机总是会时不时的出现失去平衡，我们把代码测试了好几遍，删除了越来越多的代码来确定问题出现在哪里，但是我们还是没有把这个失衡的问题解决。
After a long night of debugging where less and less things were making sense we didn't really know what to do. One of the team members got so tired of everything that he leaned back, put his shoes up on the table and closed his eyes for a while. Suddenly, the bug didn't appear any more. Tired and out of ideas we started joking around about his shoes maybe being a magical cure for the bug. He played along and started taking his shoes up an down from the table. The freaky thing was that the bug actually wouldn't appear when his shoes were on the table, but did appear when they weren't. After a while we actually started considering that there could be a correlation. Half laughing, half crying of exhaustion we actually did 10-20 runs with feet on table / feet off table and the bug happened exclusively when his feet was off the table. I think this probably was one of my most confusing moments in life, at least related to technology.
经过一夜不眠的调试，我们开始发觉调试代码越来越没有意义，不知道该做什么，我们团队中的一员开始对我们的调试工作感到厌倦了，干脆就倾斜着身子，脚搭桌子上闭着眼镜休息。突然，我们发现问题没有再出现，又困又累的我们感到十分惊喜，开始开玩笑说也许他的鞋是这个bug的克星，于是我们开始玩性大发，测试在鞋没有在桌上和在桌上两种情况下的不同测试结果。非常诡异的事情出现了：当我们把鞋放桌上的时候bug就消失不见了，当把鞋拿开的时候，bug又出现了！过了一会我们才开始仔细考虑这两者之间的关联，我们哭笑不得，在测试了10到20次“鞋在桌上和鞋不在桌上”的测试以后，也许这件事是我一生中经历过最困惑的事情，但是最后我们还是靠科技解决了这个问题。
That's when it hit us. Common ground! Turns out we forgot to connect ground between two parts of the system which led to communication between them being extremely unstable and sensitive to pretty much anything. When my teammate put his feet on the table, he connected ground between the two parts of the system with his shoe and the table where the other part of the system was located. Even though this connection was probably extremely weak, it was enough to make make the communication a little more stable. As soon as we realized what happened, we connected the missing wire and everything was running perfectly (well, at least in regards to that problem).
大地！从我的脑海中突然蹦出来。原来我们忘了将系统中的两个部分接地，导致两个系统之间的联系非常不稳定而且几乎对任何东西都十分敏感。所以当我的队友把他的脚搭在桌子上的时候，他用他的鞋把系统的两个部分接地了。即使这种通信非常微弱，也足够让这两部分的通信更稳定了。当我们明白是怎么回事的时候，我们补充了我们之前忘了添加的电线，结果一切都正常了。
来自
http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
#39
赞
#40
搞不到妹子，，，，，
#41
一个人苦干，傻干，没有团队支持，或者说根本没有团队
#42
就是：怎么成为马云那样的成功人士
#43
卖艺不如卖身
#44
编写书上的例子，代码都对却不能正常运行
#45
我记得是有次是 sqlserver 转 oracle
程序要支持，数据库也要支持。。。
程序要支持，数据库也要支持。。。
#46
有一次，公司的服务器重装linux系统，上面有3个数据库，我只备份了一个就重装了，然后其他两个系统的数据再也找不回来了
#47
客户提供的jar包内class文件的包名和所在包名不一致，，，，，各种重新发布、clean编译后的class文件、、、、、、就是找不到源文件
#48
2楼太赞了。
#49
找不到对象,自己new一个啊
#50
哇塞，虽然看不懂，但是感觉好牛逼的样子。
外贸女 VS IT男交友群： 308708519
外贸女 VS IT男交友群： 308708519
#1
需求总是调整，刚写完的模块又要修改
所以之前需求一定要沟通好，框架模块尽量松耦合，随时适应变化
所以之前需求一定要沟通好，框架模块尽量松耦合，随时适应变化
#2
回想起这个bug，仍然让我有些痛苦。作为一个程序员，在发现bug时，你学会了首先在自己代码中找问题，或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。
这是我遭遇一个硬件bug的故事。
抛开别的不说，我曾为《Crash Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情，但我一直回来处理这个bug——几天内每天几个小时。这个bug实在烦人。
这个bug的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。
过了一段时间，我们在Sony的制作人Connie Booth慌了。我们显然不能带着这个bug发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。
在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的bug所在。
在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？
你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现bug事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。
长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码——就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载/保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载/保存屏幕并且请求保存，然后写入卡中。
我最终以一个带有这个bug的很少量的代码结束——但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的Crash的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。
在那时——估计是凌晨3点——一个想法蹦了出来。读写（I/O）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。
时钟让不直接连接到CPU的硬件设备和cpu运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。
如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将PS1上的可编程计时器设置到了1kHz（1000跳每秒）。这是比较快了，当PS1启动的时候，默认状态大概是100Hz。因此，大多数游戏将他们的计时器设置为100Hz。
这个游戏的带头（和除我外的唯一）开发者Andy，将计时器设置为1kHz，使得Crash的动作计算更加准确。Andy喜欢矫枉过正，如果我们要模拟重力，我们应该尽可能的提高精度！
然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？
我将计时器代码注释掉。然后我就无法复原这个bug了。但是这并不表示bug被修复了，这个问题是随机发生的。万一我只是运气好呢？
几天过去了，我还是在玩我的测试程序。Bug没有再出现。我回到全部的Crash代码中，修改了加载/保存代码，在访问存储卡之前将可编程计时器重置为默认设置（100Hz），之后设置回1kHz。从此之后没有发现问题再次出现。
但是…为什么？
我重新回到测试程序上，试着检测当计时器设置为1kHz时出现的那些错误的模式。终于，我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载/保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。“等下，怎么回事？喂，再来一次！”
一旦我发现了这两件事是联系着的，就很容易重现bug：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件bug。
我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知：“不可能，这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。
那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：“我给你一个30行的测试程序，让你在动手柄的时候能够出现这问题。”他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是Sony很重要的开发者，他会试的。
第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。
我还是没有完全搞清楚问题到底在哪，但是我的印象中，从Sony总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。
但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在1kHz的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。
这是我全部编程生涯中，唯一一次因为量子力学debug的问题。
来自http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
这是我遭遇一个硬件bug的故事。
抛开别的不说，我曾为《Crash Bandicoot》写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快，我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情，但我一直回来处理这个bug——几天内每天几个小时。这个bug实在烦人。
这个bug的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。
过了一段时间，我们在Sony的制作人Connie Booth慌了。我们显然不能带着这个bug发布游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。
在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除程序中的代码，直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码，留下的就是你的bug所在。
在这样的背景下挑战在于，视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后，如何运行游戏？
你必须做的是用一个假装做真正的事情，但实际上只是做很简单的不会出现bug事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。
长话短说：我做完了。我移除了大片大片的代码，相当多，只留下了初始化代码——就是准备游戏运行系统，初始化底层硬件等等。当然，我不能显示加载/保存菜单，因为我截除了所有的图像代码。但是我能够假装用户使用（不可见的）加载/保存屏幕并且请求保存，然后写入卡中。
我最终以一个带有这个bug的很少量的代码结束——但问题仍然随机出现！在大多数情况下没啥问题，但是偶尔会失效。基本上所有的Crash的实际代码都被移除了，但还是这样。这实在是莫名其妙：留下来的代码基本上都没做什么事。
在那时——估计是凌晨3点——一个想法蹦了出来。读写（I/O）涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。
时钟让不直接连接到CPU的硬件设备和cpu运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题，硬件或者软件或者两者都会乱七八糟的。这真的，真的很糟糕，并且通常导致数据损坏。
如果我们的初始化代码以某种方式弄乱了计时会怎么样？我又看了一遍测试程序中和计时有关的代码，并注意到我们将PS1上的可编程计时器设置到了1kHz（1000跳每秒）。这是比较快了，当PS1启动的时候，默认状态大概是100Hz。因此，大多数游戏将他们的计时器设置为100Hz。
这个游戏的带头（和除我外的唯一）开发者Andy，将计时器设置为1kHz，使得Crash的动作计算更加准确。Andy喜欢矫枉过正，如果我们要模拟重力，我们应该尽可能的提高精度！
然而如果提高计时器频率莫名其妙的干扰了整个程序的计时，故而将这个计时器设置到存储卡的波特率上会怎样呢？
我将计时器代码注释掉。然后我就无法复原这个bug了。但是这并不表示bug被修复了，这个问题是随机发生的。万一我只是运气好呢？
几天过去了，我还是在玩我的测试程序。Bug没有再出现。我回到全部的Crash代码中，修改了加载/保存代码，在访问存储卡之前将可编程计时器重置为默认设置（100Hz），之后设置回1kHz。从此之后没有发现问题再次出现。
但是…为什么？
我重新回到测试程序上，试着检测当计时器设置为1kHz时出现的那些错误的模式。终于，我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做，所以我没有注意到（为啥我要在测试加载/保存代码的时候用手柄）。但是有一天我们的美工等我去完成测试（我确定那时候我在爆粗口），而他紧张的摆弄着手柄。卡损坏了。“等下，怎么回事？喂，再来一次！”
一旦我发现了这两件事是联系着的，就很容易重现bug：开始写入存储卡，动一下手柄，存储卡损坏。在我看来完全是硬件bug。
我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知：“不可能，这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。
那个工程师给我打电话了，他用着他的烂英语，我用着我更烂的日语，我们争论一会。我最后说：“我给你一个30行的测试程序，让你在动手柄的时候能够出现这问题。”他答应了。他向我保证，这是浪费时间，而他正在一个新项目上很忙，但因为我们是Sony很重要的开发者，他会试的。
第二天晚上（我们在洛杉矶，而他在东京，所以对于我来说是晚上而他是到了第二天），他给我打电话，不好意思的向我道歉。这是个硬件问题。
我还是没有完全搞清楚问题到底在哪，但是我的印象中，从Sony总部的反馈听到的是，如果将可编程计时器设置到足够高的时钟频率，会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器，同时也设置手柄的波特率。我不是搞硬件的，所以对于细节我相当模糊。
但是主旨是主板上两个独立部分的串扰，以及手柄接口和存储卡接口数据发送的结合在1kHz的时钟频率下会导致丢位，从而数据丢失，以致卡损坏。
这是我全部编程生涯中，唯一一次因为量子力学debug的问题。
来自http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
#3
需求变更，这是遇到的最令人无解的问题。
#4
房价问题。。。。。。。。。。。。写死了编码都买不起房子。。。。。这问题太蛋疼了
#5
写人生代码最难
经过20多年的学习、熏陶、训练。。。等到了工作时了，发现这些东西竟然都全无用武之地！首先是，应该的不如领导的一句话，讲理者被喻为情商低下（因为当你碰壁无数时终能发现：和领导不能讲理，和长辈不能讲理，和流氓不能讲理，。。。）做的再多，只要不合领导心思就全部为0。。。失败多了会让人懒惰，勤快人活该受罪。。。
--------这些 bug 你发现了吗？改了吗？
#6
需求变化是经常有的事。
在之前的公司，我同事用asp.net开发完一个项目，结果客户说不好用，说没象C/S那样可以方便使用，结果老板又重新叫我和那个同事用sliverlight开发同样一套出来，客户还是说有一点上问题而不用，期间我至少参与开发两个月。
直到我离开公司的那一天，那个项目都没得上线。
不是技术有多牛，就能推动项目上线，客户是否配合？也是项目能否上线的原因之一，项目不上线，钱是永远不能回收的，钱收不回对于技术公司来说打击最大，有的甚至因此而倒下。
在之前的公司，我同事用asp.net开发完一个项目，结果客户说不好用，说没象C/S那样可以方便使用，结果老板又重新叫我和那个同事用sliverlight开发同样一套出来，客户还是说有一点上问题而不用，期间我至少参与开发两个月。
直到我离开公司的那一天，那个项目都没得上线。
不是技术有多牛，就能推动项目上线，客户是否配合？也是项目能否上线的原因之一，项目不上线，钱是永远不能回收的，钱收不回对于技术公司来说打击最大，有的甚至因此而倒下。
#7
一个工控程序，电梯的调度算法，一直和自己的程序运行的不一致，最后发现是硬件问题！
#8
硬件bug非常难发现啊
#9
楼上的基本都不是BUG
#10
做到一半 客户该需求
#11
X总，这个要加钱，哪有白改的，做需求的时候你可是都签了字同意的！
#12
问题的根本是，不合领导的心思全部为零，领导否决你的原因是不是引导往你更优的方向走呢，如果不是，你可以与他据理力争
#13
看来客户需求变更才是项目最大的难题，而不是技术
#14
没钱
#15
3D场景的A*寻路
#16
代码不是问题，问题是人
#17
微软的所有UI平台都支持MVC设计模式,
多提供一个SL版而已,如果曾经做过SL项目,几乎不需要编写代码,
你们居然又重新开发一遍,重复劳动,又耽误时间
#18
这是软件系统的4个基本问题:
1.问题域的复杂性:
系统的复杂性远远超出了程序员的知识范畴;
2.交流问题
技术专家和领域专家知识的断层影响了交流;
3.需求的变化
系统成分的从最易变化的到最稳定的依次是:功能,接口,数据,对象(域);
4.复用:
软件生产各种工序,分析级,设计级,实现级各个级别上的复用
现代OOAD方法在以上几个方面提供了强有力的支持
#19
不符合MVC思想，而且给程序的扩展维护，人员的分工合作带来很大的困难，美工只懂HTML代码，而大量的java代码在页面，显而易见！程序的可读性差，你自己想想，大量的代码全部混合在页面看代码有多费力
#20
这个人生bug你身上还真不少：和领导讲理不是找死吗？
你要讲的不是谈待遇，而是你有多大为公司创造价值的能力！
先体现你的能力吧---通过你所创造的价值，待遇问题---领导不是瞎子。。。
#21
每一个新问题都是最难的
#22
买不起130M的房子,买不起宝马530Li
这目前就是我最难的了..
这目前就是我最难的了..
#23
总会有的，钱多到一定境界你就感受不到钱的存在了
#24
#25
价值分2种，有形的，可用金钱计算的；无形的，你的说话做事做人是不是让周围的人觉得舒服可人
#26
你要表达的观点是……
#27
最难的莫过于，我想搞oracle，领导却让我把oracle代码改成mysql
#28
房价问题。。。。。。。。。。。。写死了编码都买不起房子。。。。。这问题太蛋疼了
#29
遇到了喜欢的车没钱买怎么办
#30
#31
一般难的复杂的问题 耗时特别长的都评估下值不值得做，实际上很多难的问题都推掉了
当然这辈子最难解决的问题就是---没钱
当然这辈子最难解决的问题就是---没钱
#32
如何才能搞到妹子。。。。
#33
#34
目前来说，碰到的最难的是这个： [木星文]B2C3DB8BC88C5F0287C4C05C2734455C6DEEFCF3F2B758076635E9A90AB64A36B6097AD9D0D6031AC5DED8B76ACCB91FD3C2B5203F16013C3E29767F62A6A978158711A0EC692073DF63D24672CEF85A2A30F389B100CA9E3CC8A2F4295DC49210F093C0C1260E5234FF7012388D8E35D1C238DA7935001B4A4F0875FDAF2EBE8051281D5682E8EF41670CFBA4C167E7AF88C4B23B0AC0715E320F45D7253859
木星文翻译请通过我博客上的地址翻译哈
木星文翻译请通过我博客上的地址翻译哈
#35
我是写给有缘人看的，你只管安心做个码农就得了
#36
超级赞的经验~~~~~
#37
前端视频获取码流后（H264标准码流），加入私有头写入录像文件，但是录像文件是快放的；码流解析的时候发现I帧和P帧的时间戳都有问题；但是重获取码流到写入文件，数据都是完全正确的；搞了很久，最后发现该码流必须用二进制文件存储文件，普通方式存储就好出现跳帧问题
#38
自己翻译的，翻译得不好请原谅
So, while studying electrical engineering at school, we had a class where you were supposed do a project related to embedded systems. Me and two classmates really enjoyed the course and decided to build an autonomous RC helicopter. We attached a MCU to a helicopter to control the servos with some input from an accelerometer. The project was a little to ambitious for the 3 month class, especially since we were all new to embedded systems. But it was very fun, and we worked hard, so things were moving along fine.
在我还在学校学习电子工程的时候，我们有一堂课是学习嵌入式系统工程，我还有我的两个同学非常喜欢这堂课，而且我们准备自己动手造一个遥控直升机。我们绑了一块写入了加速计指令的MCU芯片在直升机上来控制舵机〔自动驾驶仪附件〕。这个工程对于3个月时间的课程来说有点野心太大了，而且我们都还只是嵌入式系统的新手。但是我们非常认真也非常努力，所以我们刚开始做的还不错。
One late evening we sort of had all the different parts of the system working and were ready to mount it all on the helicopter to start doing trial flights. The only problem was that once we started the system, the servos wen't bananas every now and then. We went over all code several times, removed more and more pieces the system but still couldn't get rid of this behavior.
有一天深夜，我们仍然在调试中。差不多把系统每一个部分都调试到了理想水平而且我们准备开始第一次测试飞行。唯一的问题是，当我们启动系统的时候，直升机总是会时不时的出现失去平衡，我们把代码测试了好几遍，删除了越来越多的代码来确定问题出现在哪里，但是我们还是没有把这个失衡的问题解决。
After a long night of debugging where less and less things were making sense we didn't really know what to do. One of the team members got so tired of everything that he leaned back, put his shoes up on the table and closed his eyes for a while. Suddenly, the bug didn't appear any more. Tired and out of ideas we started joking around about his shoes maybe being a magical cure for the bug. He played along and started taking his shoes up an down from the table. The freaky thing was that the bug actually wouldn't appear when his shoes were on the table, but did appear when they weren't. After a while we actually started considering that there could be a correlation. Half laughing, half crying of exhaustion we actually did 10-20 runs with feet on table / feet off table and the bug happened exclusively when his feet was off the table. I think this probably was one of my most confusing moments in life, at least related to technology.
经过一夜不眠的调试，我们开始发觉调试代码越来越没有意义，不知道该做什么，我们团队中的一员开始对我们的调试工作感到厌倦了，干脆就倾斜着身子，脚搭桌子上闭着眼镜休息。突然，我们发现问题没有再出现，又困又累的我们感到十分惊喜，开始开玩笑说也许他的鞋是这个bug的克星，于是我们开始玩性大发，测试在鞋没有在桌上和在桌上两种情况下的不同测试结果。非常诡异的事情出现了：当我们把鞋放桌上的时候bug就消失不见了，当把鞋拿开的时候，bug又出现了！过了一会我们才开始仔细考虑这两者之间的关联，我们哭笑不得，在测试了10到20次“鞋在桌上和鞋不在桌上”的测试以后，也许这件事是我一生中经历过最困惑的事情，但是最后我们还是靠科技解决了这个问题。
That's when it hit us. Common ground! Turns out we forgot to connect ground between two parts of the system which led to communication between them being extremely unstable and sensitive to pretty much anything. When my teammate put his feet on the table, he connected ground between the two parts of the system with his shoe and the table where the other part of the system was located. Even though this connection was probably extremely weak, it was enough to make make the communication a little more stable. As soon as we realized what happened, we connected the missing wire and everything was running perfectly (well, at least in regards to that problem).
大地！从我的脑海中突然蹦出来。原来我们忘了将系统中的两个部分接地，导致两个系统之间的联系非常不稳定而且几乎对任何东西都十分敏感。所以当我的队友把他的脚搭在桌子上的时候，他用他的鞋把系统的两个部分接地了。即使这种通信非常微弱，也足够让这两部分的通信更稳定了。当我们明白是怎么回事的时候，我们补充了我们之前忘了添加的电线，结果一切都正常了。
来自
http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
So, while studying electrical engineering at school, we had a class where you were supposed do a project related to embedded systems. Me and two classmates really enjoyed the course and decided to build an autonomous RC helicopter. We attached a MCU to a helicopter to control the servos with some input from an accelerometer. The project was a little to ambitious for the 3 month class, especially since we were all new to embedded systems. But it was very fun, and we worked hard, so things were moving along fine.
在我还在学校学习电子工程的时候，我们有一堂课是学习嵌入式系统工程，我还有我的两个同学非常喜欢这堂课，而且我们准备自己动手造一个遥控直升机。我们绑了一块写入了加速计指令的MCU芯片在直升机上来控制舵机〔自动驾驶仪附件〕。这个工程对于3个月时间的课程来说有点野心太大了，而且我们都还只是嵌入式系统的新手。但是我们非常认真也非常努力，所以我们刚开始做的还不错。
One late evening we sort of had all the different parts of the system working and were ready to mount it all on the helicopter to start doing trial flights. The only problem was that once we started the system, the servos wen't bananas every now and then. We went over all code several times, removed more and more pieces the system but still couldn't get rid of this behavior.
有一天深夜，我们仍然在调试中。差不多把系统每一个部分都调试到了理想水平而且我们准备开始第一次测试飞行。唯一的问题是，当我们启动系统的时候，直升机总是会时不时的出现失去平衡，我们把代码测试了好几遍，删除了越来越多的代码来确定问题出现在哪里，但是我们还是没有把这个失衡的问题解决。
After a long night of debugging where less and less things were making sense we didn't really know what to do. One of the team members got so tired of everything that he leaned back, put his shoes up on the table and closed his eyes for a while. Suddenly, the bug didn't appear any more. Tired and out of ideas we started joking around about his shoes maybe being a magical cure for the bug. He played along and started taking his shoes up an down from the table. The freaky thing was that the bug actually wouldn't appear when his shoes were on the table, but did appear when they weren't. After a while we actually started considering that there could be a correlation. Half laughing, half crying of exhaustion we actually did 10-20 runs with feet on table / feet off table and the bug happened exclusively when his feet was off the table. I think this probably was one of my most confusing moments in life, at least related to technology.
经过一夜不眠的调试，我们开始发觉调试代码越来越没有意义，不知道该做什么，我们团队中的一员开始对我们的调试工作感到厌倦了，干脆就倾斜着身子，脚搭桌子上闭着眼镜休息。突然，我们发现问题没有再出现，又困又累的我们感到十分惊喜，开始开玩笑说也许他的鞋是这个bug的克星，于是我们开始玩性大发，测试在鞋没有在桌上和在桌上两种情况下的不同测试结果。非常诡异的事情出现了：当我们把鞋放桌上的时候bug就消失不见了，当把鞋拿开的时候，bug又出现了！过了一会我们才开始仔细考虑这两者之间的关联，我们哭笑不得，在测试了10到20次“鞋在桌上和鞋不在桌上”的测试以后，也许这件事是我一生中经历过最困惑的事情，但是最后我们还是靠科技解决了这个问题。
That's when it hit us. Common ground! Turns out we forgot to connect ground between two parts of the system which led to communication between them being extremely unstable and sensitive to pretty much anything. When my teammate put his feet on the table, he connected ground between the two parts of the system with his shoe and the table where the other part of the system was located. Even though this connection was probably extremely weak, it was enough to make make the communication a little more stable. As soon as we realized what happened, we connected the missing wire and everything was running perfectly (well, at least in regards to that problem).
大地！从我的脑海中突然蹦出来。原来我们忘了将系统中的两个部分接地，导致两个系统之间的联系非常不稳定而且几乎对任何东西都十分敏感。所以当我的队友把他的脚搭在桌子上的时候，他用他的鞋把系统的两个部分接地了。即使这种通信非常微弱，也足够让这两部分的通信更稳定了。当我们明白是怎么回事的时候，我们补充了我们之前忘了添加的电线，结果一切都正常了。
来自
http://www.quora.com/Software-Engineering/Whats-the-hardest-bug-youve-debugged
#39
赞
#40
搞不到妹子，，，，，
#41
一个人苦干，傻干，没有团队支持，或者说根本没有团队
#42
就是：怎么成为马云那样的成功人士
#43
卖艺不如卖身
#44
编写书上的例子，代码都对却不能正常运行
#45
我记得是有次是 sqlserver 转 oracle
程序要支持，数据库也要支持。。。
程序要支持，数据库也要支持。。。
#46
有一次，公司的服务器重装linux系统，上面有3个数据库，我只备份了一个就重装了，然后其他两个系统的数据再也找不回来了
#47
客户提供的jar包内class文件的包名和所在包名不一致，，，，，各种重新发布、clean编译后的class文件、、、、、、就是找不到源文件
#48
2楼太赞了。
#49
找不到对象,自己new一个啊
#50
哇塞，虽然看不懂，但是感觉好牛逼的样子。
外贸女 VS IT男交友群： 308708519
外贸女 VS IT男交友群： 308708519