首页英雄联盟正文

bug代码,改别人代码的bug

英雄联盟 2年前(07-25) 132

1、bug代码，改别人代码的bug？

改别人写的代码觉得吃力，这个完全体现不了一个人的技术菜不菜。为什么？原因答主根据自己的经验从以下几个点给分析分析：

外在因素

工具的使用习惯不同

bug代码,改别人代码的bug

大家应该有遇到过这种情况，我们可能在看到其他人使用和你一样的开发工具的，但是你发现他把开发工具的窗体上的模块都调的和你的使用习惯完全不一样的，比如：你的资源管理器在左边，但是他把资源管理器调到了右下角。那这个适合你来给他找bug刚开始真的会觉得很麻烦，总感觉不舒服，并且你还不能调。这样会严重的影响你的找bug效率。

当工具使用习惯不一样的时候也会有所影响

代码的风格不同

所谓的代码风格不一样，打个比喻：你敲的代码每个变量名的命名都是按照规定的需求文档来，绝对没有一点差错，但是你看到对方的变量名总是一些奇奇怪怪的单词的组合。在或者你习惯把成员变量放在类的最上面，但是别人习惯把成员变量放在当前要使用的方法上面，等等等等。虽然这个对于找bug没有实质性的影响，但是相信很多小伙伴有这种感觉，总感觉不舒服，每次看到这里和自己的风格不一样，心里总是会咯噔一下。这应该叫做影响心情吧！！！

业务逻辑的理解思路不同

对于同一个模块的业务功能，大家会根据自己的业务逻辑的理解，找到解决方案，或者说同一个业务模块，你理解的业务逻辑和他的会不一样，那么你的解决方案也就不一样。所以在给他找bug的时候你会经常遇到看不懂的代码，这个看不懂也不是说你比较菜，是你不理解他现在的想法，所以你如果要继续往下面找的话，必须要问他来理解他敲出来的代码的他的想法，这样就会很麻烦很麻烦，如果他能正确的表达他的思路还好，如果表达不清楚那就会花费很多的时间了。所以二手代码对于所有程序员来说真的是噩梦，你会在看代码的时候内心疯狂的吐槽前开发者。

每个人的业务逻辑理解可能不一样，所以沟通成本会比较大自身因素

对当前遇到的技术不够熟悉

自身对于技术的不熟练才是找bug吃力的最主要原因，但是不是绝对因素。如果对于当前使用的技术不够熟练，会导致遇到的bug你也在内心是摸棱两可的，也不确实，之后你会在各种调式中去试，如果运气好，你可能试个几次找到原因，如果运气不好，可能把你觉得有问题的都试完都找不到。那这个时候你在对别人说不好意思你也找不到，那你这完全是在浪费时间，有可能还会招到别人的吐槽。但是你的对现在用到的这个技术了如指掌，那你每个模块检查完毕，基本跑一跑你就能缩小范围然后调试之后就能确定问题所在了。

技术才是核心

对业务逻辑理解的不够透彻

也有一种可能你不是负责这个模块的，然后别人给你讲了讲现在他的模块业务功能，然后对于业务功能的不熟练也会导致你在找bug的时候一边找一边去想业务逻辑，效率会很低，你找的肯定会很吃力。

总结：别人出现bug能拜托你去帮忙的话，已经证明了你在他内心技术是足够好的，找bug吃力的原因有很多，但是对于技术的熟练也还是最主要的原因，但也不是绝对原因。

以上是答主个人看法，如果有帮到您，麻烦点赞，评论，加关注谢谢！

2、win键加r的代码如何出现bug？

打开“运行”快捷键win+r不能用，可能是被禁止了，启用方法如下：

1、在任务栏搜索编辑组策略，并点击打开。

2、导航到以下位置：用户配置>管理模板>Windows 组件>文件资源管理器。然后双击右侧窗口的“关闭Windows 键热键”。

3、在出现的窗口里选择“未配置”或者“已禁用”。点击“应用>确定”。

以上方法应该能解决。

3、大家觉得是编程能力的哪一方面出了问题？

这款可视化神器查找Bug更容易——Anteater追踪程序执行过程，让Bug定位更迅速

代码调试一直是让广大程序员头疼不已的工作，新人尤其容易中招。最让程序员们抓狂的情况莫过于程序没有报错，输出的结果却不符合预期，如果面对的是一个冗长复杂的程序，则更是无从下手。

程序调试的一种常见做法是手动检测程序，收集可疑变量x（下图第一行）并打印出x的值，通过观察x值来发现bug，但这种方法本身很容易出错；另一种常见的做法是设断点调试（下图第二行），使用调试器自动停止程序执行，并单独查看x每次的赋值，但断点调试往往只能逐次提供一个小的值视图，不方便观察分析。

已有的大部分可视化调试工具都有一个明显的缺点：缺少变量和表达式的全局值视图，而Anteater这个用于跟踪和探索程序执行的交互式可视化系统则克服了这个困难。Anteater能够自动检测源代码，捕获程序执行的行为以及用户指定的变量和表达式，然后通过交互式可视化呈现程序执行的信息。

Antater能自动插入代码，跟踪变量及其执行结构的上下文。它向程序员提供了交互式可视化功能，并提供了值的全局视图，从而可以轻松地检测错误值并进行交互；缩小可视化范围，从而可以检查特定的值，更容易发现bug。

下图展示了Anteater系统的工作流程。首先，用户使用Anteater接口选择要跟踪的变量，定义跟踪规范。这个跟踪规范与源代码一起，通过Web接口发送到Python后端。然后，Anteater跟踪程序，检测源代码，以收集执行信息以及指定的值。下图右侧显示了该系统的简化版本，在对代码进行检测之后，使用python来创建程序跟踪。这个跟踪通过Web界面传回到Anteater前端，进行可视化并呈现给用户。

Anteater可提供跟踪变量的接口。比如，在下面的Python代码中，用户可以选择想进行跟踪的变量和表达式，右键单击，进行跟踪。用户还可以选择函数调用和库导入，将它们从跟踪中排除。

为了展示Anteater在变量跟踪中的强大功能，用Anteater来分析一下六种梯度下降算法的效果。观察的六种方法依次是Vanilla, Momentum, Nesterov, Adagrad, Rmsprop, 和Adam。交叉点的数量（变量num_intersections）以及最小交叉角度（变量min_angle）这两个变量在梯度下降算法的每次迭代中都会改变，通过观察这两个变量值的变化来判断几种算法的效果。

下图展示了通过观察变量num_intersections的变化来选择梯度下降算法的过程。（目标：最小化num_intersections）（A）图概述了6种梯度下降法的行为，观察散点图可知，最后三种方法（Adagrad, Rmsprop, 和Adam）会立刻卡住。因此，下一步只需比较Vanilla, Momentum和Nesterov这三种方法的效果。（B）图中的Vanilla梯度最初朝着一个较差的值（一个大的值）移动，但在最后下降到了一个较好的值（一个小的值）。（C）图显示了在Momentum法中，每次num_intersections下降到一个较好的小数值时，又会重新跳到一个较差的大数值上，而（D）图中的Nesterov方法也有这样的特点。因此，从优化num_intersections值的角度考虑，Vanilla梯度下降法效果最好。下图则展示了通过观察变量min_angle的变化来选择梯度下降算法的过程。（目标：最大化min_angle）（A）图概述了6种梯度下降法的行为，观察散点图可知，最后三种方法（Adagrad, Rmsprop, 和Adam）要么立即卡住，要么只是略有增加。（B）图中的Vanilla梯度一开始表现较差，但经过一段时间的迭代，最终达到了一个较好的大数值。（C）图所示的Momentum法，每当min_angle达到一个较好的大数值时，就会迅速开始下降。（D）图中的Nesterov也表现出类似的规律。因此，从优化min_angle值的角度考虑，仍然是Vanilla梯度下降法效果最好。

Anteater的开发者还在TE问题（Tennessee Eastman）上进行了挑战，提出了一个化工厂的开放基准，考虑了真实世界中的各种复杂因素，以此来展示Anteater在工业应用中的可行性。

（F,G,H表示三种产物，NaN值代表装置爆炸的设定值，即当反应堆压力超过3000kPa时,会发生爆炸。）

上图是使用Anteater系统进行的展示。（A）图表明成本（Cost）和总产量（Total Production）相关，可以找到低成本且高产量的解决方案。黑点表示在优化的最后一次迭代中达到的解决方案。在（B）图中，反应器温度（Reactor Temperature）参数中较高的值对应更高的总产量（Total Production），爆炸可能性较小。（C）图表明在优化过程中，H和G是相互竞争的关系，高G值对应低H值。在（D）图中，反应器水平（Reactor Level）值影响产物F的产生，低反应器水平对应于高F产量，并且在更高的反应水平下，发生的爆炸更少。

上面这两个案例展示了Anteater可视化程序运行和发现程序问题方面独有的优势。至于如何更充分地利用这个神器，各位程序猿可参考：Anteater: Interactive Visualization for Program Understanding，用好bug查找神器，让代码调试更高效！

更多科技知识可关注 @人民邮电出版社头条号，我们会持续推出优质的计算机知识和图书资源！