写很很透彻，把码农解决bug的过程都包含进去了，至少我就是这样的。下面的文章和《各种流行的编程方式》有异曲同工，请你不要理解错了。本文来源，翻译如下：——————————————————一个非常严重和困难的bug，能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯。经受这种考验的创伤程度，相当你受到了一次严重的身体伤害，离婚，或是家庭成为的离世。研究人员在研究了计算机编程心理学后，得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界，很像为大众所知的Kübler-Ross Stages of Grief（这个模型描述了人对待哀伤与灾难过程中的5个独立阶段（否认，愤怒，耍赖，抑郁，接受）。绝症患者被认为会经历这些阶段），而且原因都很相似。就好像死亡所伴随的悲伤一样，fix一个bug是一个过程其初始化了一个事件，一开始是拒绝相信，其造就了你苦闷的情绪并开始逐步影响你的心智。这种苦闷的情结果会让你纠结要努力忍受，最终会你会找到一个满意的结果。了解下面这几个bug-fixing的阶段，会让我们更好的生存下来，并持之以恒，最终带来……关闭我们所有的bug的结果。第一阶段：抵触本阶段的状态: 多疑 Skeptical. 生气 Offended. 易怒 Petulant.1. 不理睬也许这个bug会安静地离开。2. 标记上“不是bug”也许这是用户的错，或是本地配置有问题。是的，我确信就是那样，一会就会好的。3. 就是一次小故障我想这就是一次小故障，很奇怪地发生了一次，它不会再发生的，虽然没有搞清楚是为什么发生了，不过这就好像我们的数据库，网格，浏览器或别的什么打了几个嗝一样。一会就会好的，我确信。4. 躲藏.我要休几天病假，也许他们会把这个bug转给别人的。5. 标记为“修改需求中”你看，我是按照需求实现的。如果你们想要改这个行为和UI，就一定要修改需求。也许他们会决定就这样了。6. 需要更多的信息我不能确定这是一个bug，除非我能在错误日志中看到一条特定的报错信息。7. 转给其他人我调查这个bug中看到了其它模块中我看不懂的数据，问题很大。我应该把这个bug转给开发那个模块的人。我可以在我的模块中检查一下那个边边角角的情况，但是正确的fix应该是在别人的模块中。反正那个在别的国家，我见不着他。第二阶段：接受本阶段的状态: 认命 Resigned. 被打击 Defeated. 被激怒 Annoyed.1. 接受现实行了，行了，行了！这是我的bug，我会修正它的。2. 把这个bug放到最后也许，我可以在我需要fix这个bug之前找到一个新的工作。3. 和你的经理讨价还价好的，你看，我可以正确地fix这个问题，不过我需要一个月。也就是说，我可以给这个问题贴个创可贴，那不会真正的解决它，但是我们可以避免用户的抱怨，这可以为我们赢得几天的时间。4. 为这个bug标记一个无耻的时间上帝啊，我希望这时间够了。第三阶段： 投入和沮丧本阶段的状态: 眼花 Giddy. 头晕 Light-headed. 紧张 Nauseous.1. 开始调查我能搞定它，我能搞定它！只需要小小的调整一下，小小的关注一下，多一点咖啡因，再加上一点时间，我能搞定它。2. Befuddlement.Shit. 这太扯了。我居然没有一点进展。这代码真是乱。这样的代码居然能编译和运行，真TMD的神奇，我有机会能搞清楚它什么不正常吗？3. 再次躲藏你看，很对不起。我不得不要去切除我的阑尾。再一次，是的，既然你提到了它，我的确有两个阑尾。现在我一个也没有了，你高兴了吧？。4. 犯贱好吧，总之，你到底期望什么？想让我在一个没有高级调试器的环境下改这个BUG。我是什么？千里眼吗？我在我的Commodore 64上一个更好的调试器！5. 瞎搞看看我试试这么改？Kao，这样不行。要不然这样搞？也不行。那么那样搞呢？Shit，虽然再糟糕。6. 绝望我不可能fix这个bug了。我是个糟糕的程序员。我太笨了。我在这个满是聪明人的地方干什么？迟早他们会知道我的能力太差，那时我就玩完了，在这也混不下去了。7.耻辱我的经理问我为什么我用了一个月的时候来fix这个只需要两天就可以解决的bug？老实说，我不知道怎么去读日志信息，我搞坏了我们的编译脚本。现在，我不敢去让别人来帮我，因为这样只会让我显得更愚蠢。8. 恐慌！这事变得比我相像的要复杂！而我开始觉得复杂的事变得简单……而我觉得简单的事变成需要重定半打的类。为什么我以前在我的经理前拍着胸说我可以搞定这个事？9. 通宵工作，远离朋友和家人(语无论次的喃喃自语，一阵一阵地大声咒骂)第四个阶段：愚蠢的快感本阶段的状态: 感恩 Grateful. 安心 Relieved. 极端地自我欣赏 Awfully Impressed with Yourself.1. 醒悟哦！我终于明白怎么搞定它了……2. 写正确的代码我真NB，我是编码机器！3. 测试牛！通过一个测试。真牛！又通过一个测试了。靠！有测试失败了。这是为什么……4. 隐藏测试失败反正这完全是一个不重要的测试案例。没有人会检查它，这个测试真是毫无意义。5. 提交代码我太牛了，厨房里有个馅饼可以庆祝一下吗？6. 关闭 bug.我听说那里有个馅饼可以庆祝一下第五个阶段： 与“完成”肉搏本阶段的状态: 焦燥不安 Twitchy. 神经过敏 Nervous. 迷信 Superstitious.1. 有人reopen了这个 Bug真的？他们发现了你引入了另一个bug？ Shit – 那只是一个不重要的案例永远不会发生的。2. 修正以前的修正是的，我甚至检查了员工的年龄是一个虚数的情况，就是为了防止出错。3. 关闭 bug是的，贱货，你被关闭了。全部都关了，再也不用心烦了。4. 发誓以后再也不干这种事了5. 大家都意识到你现在是那个模块的专家了哦，不！现在他们又给了我三个那个模块的新bug没关系，现在你只需要GOTO 第一个阶段。此外，作为一个工作中的程序员，你会永远经历这些烂事，直到你——死亡，退休，或是被升到管理层。（全文完）原文网址：http://coolshell.cn/articles/4045.html
这里我并不说是axis1和axis2的什么不同，只是最近接触到了axis1和axis2的应用而已。 情况是这样滴。 公司的系统架构是公司外部系统的接口交互都要走公司的接口层，再由接口层将信息透传给公司内部的各个系统。 接口层使用axis2来架构，我这块的接口部分是使用axis1架构的，这个框架用了好几年，相当的成熟，看代码中的注释，最早的有02年写的代码，听说是很早那一批海归写的。 按理来说，高版本一般都会是兼容低版本的，况且对于axis来说，只要是标准的wsdl就可以，可还是有些区别的。 我使用axis1可以正常调用和返回，接口层可以调用也可以返回，看日志，调用的输入和输出都是正常，可在接口层那边就是取不到数据。同事和我整整查了一中午问题，公司对接口很厉害的高手也没有个办法。 最后，还是用最底层的办法来查，webService的本质还是xml，查看输入和输出的xml，输入没有什么问题，输出还是发现了一些端倪。 作为一个返回对象，属性内容是包含在ns的标签中的，在我们输出的xml文件中，ns标签标签中出现的是mutilhref="#01" ，在ns的标签外面，有个#01的标签，在#01中包含着输出的内容。接口层使用的是axis2取数据是从ns的标签中取的，当然是取不到标签外的值，axis1是可以取到的。 让接口层改用axis1，为了保持整个框架的统一，肯定不能改，我们改成axis2，时间不允许。有问题就google、baidu了，最近google搜索，都是搜索的繁体或者英文，简体的好些不是很方便，有时google还打不开，有些厌恶baidu的搜索了，现在用有道多一些。对于axis1和axis2的这个问题，整个网络上面，就只有一个09年的帖子提到，让关闭一些wsdd中globalConfiguration的sendMultiRefs设置为flase。 设置为false之后，再次调用，ns标签外的对象就被包含在ns中，不会采用引用的方式了。 在http://axis.apache.org/axis/java/reference.html有几个配置的解释，没看到有中文的解释，按照我自己的理解，意译下。 sendMultiRefs true/false flag to control whether multirefs are sent or not. 是否使用引用对象的方式 sendXMLDeclaration true/false flag to control whether the <?xml?> declaration is sent in messages 是否包含xml头文件的信息 sendXsiTypes true/false flag to enable/disable sending the type of every value sent over the wire. Defaults to true. 是否在每个值中都标注值的类型参数