如果你在国际上说你一天之内可以搞定15000行代码，那么别人有两种反应：①绝对要佩服你五体投地会，完全是万年难得一见的天才程序员；另一种反应②这是一个吹牛不负责任的垃圾程序员，千万不能把项目交给这样的团队。是的，我们现在的现状就是所谓的快速开发，为了利益管他三七二十一，只要把代码写出来稍微跑一下就可以交给客户了。然后客户用了五年还是在不断的发现Bug，再然后就是找不到原来的开发公司来给自己维护了。
目前绝大部分开发公司并没有去统计每个程序员的代码生产率，而只是为了利益只管把软件搞出来根本不按软件开发规范去做。如果只是简单的把代码写出来，那么每天15000也可以达到，但每一个程序你能保证代码安全，没有Bug，按照规范来做的吗？做过黑盒白盒测试吗？有用过工具来测试吗？代码Review过吗？有各种单体测试用例或Case吗？Case覆盖完全吗？造出实际数据完全跑过吗？各种规范满足吗？各种要求的文档完整吗？软件今后是否便于维护呢？
而现状就是我们绝大部分代码连简单的命名规范都没有达到，或者编码的规范，窗体或画面的规范，连每一个程序的风格都没有统一。为了快速开发，连单本程序的测试用例都只是简单的写几句甚至没有，更别说测试的证据保留。为了省事省钱，更别说要代码Review了。软件开发后每一个功能模块的测试、综合测试都马马虎虎，压力测试根本就没有。开发管理的流程更是随意，基本就是CMMI1的水平。
软件也是产品，与其它产品生产一样，是作为一个项目来做。那么就要考虑“质量、成本、进度”，为了利益很多事牺牲了质量，造成软件Bug众生，可维护性差。过后更没有进行开发过程的优化，编码分析，Bug分析等等，所以公司整体多年以后除了技术有点儿进步，整体根本就没有进步。即使开发公司本身，隔一段时间要在原有软件上修改或增加功能时，都有可能不知所措。
按正常情况，如果只是单纯的编码人员，如果所有的流程都走到，按照规范来做，Bug率控制在较低情况，一个中级Java人员为例保持在6K-7.5K行/月左右应该是算是不错的。如果是一个团队，那么这个生产率应该更低很多，因为包含了设计、管理、测试等各方面的人员。当然，这个月生产率在很多公司眼里是不入眼的，因为要快捷开发，多快好省可能比这个高得多，但最好是保证质量。
打开“运行”快捷键win+r不能用，可能是被禁止了，启用方法如下：
1、在任务栏搜索编辑组策略，并点击打开。
2、导航到以下位置：用户配置>管理模板>Windows 组件>文件资源管理器。然后双击右侧窗口的“关闭Windows 键热键”。
3、在出现的窗口里选择“未配置”或者“已禁用”。点击“应用>确定”。
以上方法应该能解决。
现在cf差的很严，卡出错误代码，都会数据异常，让你退出客户端。唯一方法是在未出错误代码前，就退出房间。
改别人写的代码觉得吃力，这个完全体现不了一个人的技术菜不菜。为什么？原因答主根据自己的经验从以下几个点给分析分析：
外在因素工具的使用习惯不同
大家应该有遇到过这种情况，我们可能在看到其他人使用和你一样的开发工具的，但是你发现他把开发工具的窗体上的模块都调的和你的使用习惯完全不一样的，比如：你的资源管理器在左边，但是他把资源管理器调到了右下角。那这个适合你来给他找bug刚开始真的会觉得很麻烦，总感觉不舒服，并且你还不能调。这样会严重的影响你的找bug效率。
当工具使用习惯不一样的时候也会有所影响代码的风格不同
所谓的代码风格不一样，打个比喻：你敲的代码每个变量名的命名都是按照规定的需求文档来，绝对没有一点差错，但是你看到对方的变量名总是一些奇奇怪怪的单词的组合。在或者你习惯把成员变量放在类的最上面，但是别人习惯把成员变量放在当前要使用的方法上面，等等等等。虽然这个对于找bug没有实质性的影响，但是相信很多小伙伴有这种感觉，总感觉不舒服，每次看到这里和自己的风格不一样，心里总是会咯噔一下。这应该叫做影响心情吧！！！业务逻辑的理解思路不同
对于同一个模块的业务功能，大家会根据自己的业务逻辑的理解，找到解决方案，或者说同一个业务模块，你理解的业务逻辑和他的会不一样，那么你的解决方案也就不一样。所以在给他找bug的时候你会经常遇到看不懂的代码，这个看不懂也不是说你比较菜，是你不理解他现在的想法，所以你如果要继续往下面找的话，必须要问他来理解他敲出来的代码的他的想法，这样就会很麻烦很麻烦，如果他能正确的表达他的思路还好，如果表达不清楚那就会花费很多的时间了。所以二手代码对于所有程序员来说真的是噩梦，你会在看代码的时候内心疯狂的吐槽前开发者。
每个人的业务逻辑理解可能不一样，所以沟通成本会比较大自身因素对当前遇到的技术不够熟悉
自身对于技术的不熟练才是找bug吃力的最主要原因，但是不是绝对因素。如果对于当前使用的技术不够熟练，会导致遇到的bug你也在内心是摸棱两可的，也不确实，之后你会在各种调式中去试，如果运气好，你可能试个几次找到原因，如果运气不好，可能把你觉得有问题的都试完都找不到。那这个时候你在对别人说不好意思你也找不到，那你这完全是在浪费时间，有可能还会招到别人的吐槽。但是你的对现在用到的这个技术了如指掌，那你每个模块检查完毕，基本跑一跑你就能缩小范围然后调试之后就能确定问题所在了。
技术才是核心对业务逻辑理解的不够透彻
也有一种可能你不是负责这个模块的，然后别人给你讲了讲现在他的模块业务功能，然后对于业务功能的不熟练也会导致你在找bug的时候一边找一边去想业务逻辑，效率会很低，你找的肯定会很吃力。总结：别人出现bug能拜托你去帮忙的话，已经证明了你在他内心技术是足够好的，找bug吃力的原因有很多，但是对于技术的熟练也还是最主要的原因，但也不是绝对原因。
以上是答主个人看法，如果有帮到您，麻烦点赞，评论，加关注谢谢！
1代码有bug却能正常运行的原因可能有以下几种情况：
1. 幸运的巧合：有时候，代码中的bug并不会在所有运行时的情况下都导致错误。可能是因为某些特定的输入或者环境条件，使得bug的影响被掩盖了。
2. 隐藏的错误路径：有时候，代码中的错误路径并没有被触发或者测试到。这可能会导致一些bug并没有真正地影响到程序的运行。
3. 潜在的错误：有时候，代码中的bug在某些情况下确实会导致错误，但是这些情况并没有被测试到或者出现过。这可能是因为测试不够全面或者没有揭示出潜在的错误。
4. 编译器或者运行环境的优化：编译器或者运行环境可能会对代码进行一些优化，使得bug的影响被消除或者丢失了。这种情况下，代码仍然会正常运行，但是可能会隐藏一些问题。
总的来说，代码有bug却能正常运行的原因是非常复杂的。这种情况下，我们仍然需要修复bug，因为在不同的情况或者环境下，这些bug可能导致错误的结果。
