如何高效Debug(又名如何高效解决问题)
如何高效Debug(又名如何高效解决问题)
简介
⭐这是一篇通用 DEBUG 文章，这篇文章适用于大部分面向对象编程语言的 DEBUG⭐
- 如果你接手其他人的项目中出现了错误，这个文章可以给你一种解决错误的思路
- 新手程序员可以通过这篇文章来学到一种 DEBUG 思路，尽管这可能不是最好的方案，但是这个方案足以应付大多数出现错误的情况
- 你可能借助这篇文章知道你现在的 DEBUG 进入到了什么状况，还有什么情况没有考虑到，你是否还有其他办法解决你的 BUG
阅读本文章须知
- 文章中为了打字方便，大多数的 BUG 将会被翻译成中文
错误 - 你需要有至少一门语言编程的经验
- 请不要大篇幅的跳读文章，这会导致你的阅读出现断层
导读
你将会了解到如何区分错误的等级，来根据不同的错误等级来请求他人的帮助，同时更加详细的错误等级同时也会提起他人的重视，然后你将会了解到在你接手代码或者准备尝试一些新的东西的时候你如何解决代码之外的问题，之后你会将目光聚焦到代码的内部，使用多种方法来更快的找到和解决错误，如果这都不能帮助你解决错误，那请尝试前往论坛或者请求身边的朋友帮忙，这篇文章会教你基础的如何提出一个好问题的方法，在文章的最后，留下了几点小建议，能够让你在写代码的时候能够更加轻松的方便后期维护，写出好的代码。
接手别人的代码如何修改错误
这一章大部分的情况都会出现在你第一次接手一个新的项目，或者拿到了一个新的模块进行测试会需要做出的准备，通常你需要弄清楚自己的问题，因为有可能这些代码在其他人的电脑上能够正常运行
你的目标是阅读最少的代码，将他人代码中的问题解决(如果是自己的代码出现问题请直接跳到下一章)
请不要在第一时间将你的错误丢给其他手头有工作的同事
请至少保证你为了解决这个错误做出了下面的这些努力，尽管这些努力没有效果
快速反应⏩
通常你可以不需要任何思考，直接将错误复制粘贴到百度或者其他搜索方法上直接进行搜索
例如:
现在报了一个错误，你可以直接复制你现在发生异常的错误报告去百度
('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
请不要复制错了信息，下面的内容不需要被复制，因为你需要将整个代码发一个帖子才能让下面的内容变得有意义
通常情况下一些小错误，经过网上其他人的解决办法就可以解决，但是如果依旧没法解决，你需要进行其他的步骤
1. 确定目标⛳
明确你的目标，你脑海里面需要有一个设想，如果没有出错，这个程序应该显示一个什么样的结果，如果实现了这个效果，那么说明这个错误已经被解决了
这个目标并非是一成不变的，你的目标应该是一个范围，因为别人写的程序你很难完全按照自己想的方式运行， 但是你能够让他尽量的靠近自己的想象，如果你想要完全和自己希望的一样，你可能需要重写大量的代码，尽管功能实现了，但从团队的角度上看这可能是在浪费时间
- 最好的情况下能够和你的预想一模一样，这当然是最好的
- 你还需要想一个最差情况，虽然没有完成预想的功能，但是并不影响正常的使用，你也算解决了错误，或者说降级了错误的等级(把3级错误降级为4级的错误)
例如我现在需要一个图形界面，我希望他的按钮能够居中
这样就算是完美的符合了要求
但是可以有一个偏差，如果不影响正常的使用，下面这样也是可以的
2. 重现错误 ♻️
检查错误是否能稳定触发，如果可以触发条件是什么
请弄清楚错误的触发条件，他是在经过了哪些操作下才会报错
- 例子
- 点击某个框后就会进行报错
- 当程序挂机一段时间就会自动崩溃
- 提醒用户输入的时候报错跳出
你需要不断的缩小你出现错误的范围，最终缩小到一个小范围内你才能进行修改
放大错误
就如标题说的，把你的错误进一步放大
有些bug现象不太明显，那么就想办法增大它的破坏性，把现象放大。这只是个思路，具体怎么放大只能根据具体的代码来定
例如：美剧《豪斯医生》里有一集，怀疑病人心肺有问题，就让病人去跑步机上跑步，加重心肺负担，从而放大症状。
遇到一个无法复现的错误
一个不能复现的错误是程序的隐患，你需要提起注意，不能因为他自己能好而掉以轻心
有的时候遇到了一个错误，但是这个错误只会在一些非常偶然的情况下触发，而且通常不用修复自己就好了
- 请做好每一次报错的记录
- 将报错的日志提交缺陷文档，或者向上级反馈
3.索要或者搜索技术文档💠
找到出错代码模块的说明文档，请先查看当前报错在文档内是否有说明，是否属于已经解决的已知错误
如果是接手的项目，那么上一位大概率会有一份说明文档，说明这个代码大概实现了什么内容，有哪些方法，如果详细一点请找一下当前你的报错是否在说明文档内，有可能别人已经有了解决方案，如果你还去问别人可能会得到一个RTFM的回复
- 如果是开源项目请尝试阅读开源文档
- 如果是公司内部的模块请向前一位索要技术文档，或者直接向他提出问题(当然是在看过文档之后)
4. 检查传入的参数🅿️
明确责任，是当前的模块错了，还是参数传递的时候就出错了，错误的数据当然就会得到错误的结果
检查你当前函数的参数是否按照预期的在传递，将当前的参数打印，然后和预期的参数进行对比
可能出现的错误：
- 传递参数的个数不对
- 传递参数的位置不对
- 传递的参数在函数内被同名变量覆盖
- 传递参数后，函数内引用错误
- 例如：参数名字拼写错误，最终报错
未定义的变量
- 例如：参数名字拼写错误，最终报错
5.检查运行环境ℹ️
有可能你现在的系统环境和代码需求的环境不一致导致了你代码出现了错误
请确保你检查过了上面的技术文档，并且开发这种模块的技术人员也没想到会出现这样的问题，这个时候你可以考虑一下是不是本机的环境出现了一点问题
- 可能的环境错误
- 本该跑在 linux 上的程序在 windows 下运行
- 没有安装相关的依赖
- 例如：没有装Java 或者包
- 例如：也许依赖本身也有依赖(依赖的依赖没有安装)
- 版本不对
- 例如：需要
python3.9实际本机安装的是python 2.7
- 例如：需要
- IDE内部错误(可以考虑更换IDE)
- 本机电脑操作文件权限不足
- 磁盘满写入
- CPU超负荷
如果所有的努力都尝试过了，你可以考虑重启一下电脑
重启大法好，BUG跑不了
在代码内寻找错误
通常情况下别人写的代码已经确认自己的电脑没有问题，但是代码还是无法运行，或者本身就是你自己写的代码，自己都运行不了，现在你就应该确定，错误来源于你的代码内部，你现在需要观察你代码的内部逻辑进行分析
1. 寻找合适的工具⚙️
工欲善其事,必先利其器
工匠要想做好活，一定要先使工具精良。形容做事要做好充分的准备。
一个好的调试工具可以帮助你更加快速的找到错误，或者更加直接一点，这个工具是你进阶到更高进阶的一个重要的技能
一般情况下选择对应的工具
- python使用pycharm
- java使用Ij
- C#使用vs
- 或者你可以直接使用vscode
相关的视频
- IDEA 断点调试 debug 会用吗？https://www.bilibili.com/video/BV1ur4y1P7SV
- IDEA 断点调试高级玩法https://www.bilibili.com/video/BV12f4y1s7UZ
- vscode调试教学https://www.bilibili.com/video/BV1CK411H7ic
2.重读程序📕
最快速的方法
通常情况下从你报错的上下文开始看，按照自己设想的思路一点点开始，一步一步的运行，看看他的变量或者程序的运行是否和自己所想的一样
很多时候都是自己在写代码的时候都忘记了自己正在写的什么，你需要重温一下，理清这个逻辑，代码自然就通了
3.测试参数📝
你对你的函数输入更多测试数据
这些输入的测试数据应该从正常然后慢慢变得夸张，来确定你发生错误的边界
常用的几个测试数据
- NaN
- None
- null
- 65566
- 128
“”空字符串- 空数组
4. 打印中间结果📇
从程序的中间打印结果
依赖于IDE的断点调试，是十分浪费时间的一种调试方法。而且在面试中，你是基本没有断点调试的机会的（因为很多公司是白板写题，不会提供给你IDE）。事实上在实际的工作中，你也很少能够有机会去进行断点调试，比如你进行的是 Web 开发，你只能想方设法的在代码中打印一些 Log，然后根据 Log 去分析出错的原因。你平时用 IDE 写代码，就十分容易养成这种断点调试的“坏习惯”。一个更好的方式，是使用打印中间结果的方式
以 LintCode 上的 Clone Graph 为例子：
LintCode 支持自己出测试数据进行测试的模式，点到“Testcase” 这个 tab之后，输入测试数据，点 Run Code。你的程序中的输出也会被显示在 Output 中。我们看到 代码中 第22行到27行，是在打印一个中间结果，这个中间结果就是在使用了 bfs 算法之后，从一个点出发，找到的所有的图中其他节点。这样我们就可以迅速验证，代码出错到底是因为 BFS 写错了，还是因为其他的部分写错了。
使用这种调试方法的另外一个好处是，你很自然的希望你的程序可以“分阶段”输出一些中间结果，这种分阶段处理的方式，也是我们在课上经常强调的，把大问题变成小问题，然后逐个击破的编程思想。养成这种编程习惯之后，可以非常有效的帮助你在写程序的时候，就避免掉错误。
5.检查判断伪判断语句⁉️
检查if语句是否符合预期，if中的判断语句是否有出错
例如 if True这样的伪判断
你先在可能还没有找到错误，接下来这些步骤都会相对的浪费时间，同时调试的成本也会相应的提高
一些条件判断语句的判断条件可能并不是非常的明显，例如调用函数的返回值进行判断，或者使用了一些其他方法，你需要知道程序走过了哪些路程
方法1：使用打印语句，在每一个判断语句的开头和结尾添加
if a<3:
print("当前进入了true语句中")
# 其他的代码内容
print("true语句执行结束")
else:
print("当前进入了false语句中")
# 其他的代码内容
print("false语句执行结束")
方法2：使用IDE自带的调试功能进行调试
这里的演示是vscode + python,IDE调试操作各不相同，请自行上网查找对应的调试教程
在判断语句中可能出现的问题:
-
永远为某个值的判断语句
- 例子：
if a<0 or True,此处判断语句永远为true
- 例子：
-
永远无法进入的判断语句
-
例子
-
def test(a): # 永远会执行这里 if True: return # 程序永远也执行不到这里 if a<3: print("a的值小于3")
-
6.控制变量(二分法定位)🎛️
在这个步骤注释掉大量可能引起错误的代码，然后分析哪些代码可能导致错误
你现在已经几乎快要读完别人的整个代码，成本已经比较高了
注释代码并非全部注释，而是分批注释
- 注释报错代码，其他的代码能否正常运行
- 注释掉一些不相关的代码，留下报错代码，查看是否有其他原因导致他报错
- 新建一个空白的文档，单独配置运行环境，查看报错代码能否正常执行
如果报错的代码哪怕单独开了一个运行环境依旧无法正常执行，请前往查看官方的模块API，或者找到模块开发者的使用说明，通常情况下是这一行代码本身没有办法达到需求，可能是模块的版本迭代，或者使用者使用了错误的语法
7.重构🔁
可能这个代码已经非常烂了，就像是大雨天压弯了的稻草，这个时候只能重构了
重构之前：
- 分析API。拿到APP源码，运行中抓包拿出所有的操作过程中使用到的API，整理记录下来。
- 分析服务器端代码，把服务器端的API接口整理记录。
- 把第一步中和第二步中产生的差异处理掉，差异是指app中调用了但是服务器端没有的，还有就是服务器端写了但是APP没有调用的。（不要问我为什么会有差异，鬼知道）
- 分析数据库，把API操作引起数据变化的表找出来，以及关联的字典表找出来。
- 把依赖的资源文件的文件夹标记出来。
开始重构：
- 设计数据库，连不规范的命名都换掉，写sql脚本把数据从库中导入进来，同时要单独处理资源的路径。
- 重写API，为了兼容现有的无法升级到APP，专门把POJO转了兼容原有代码的DTO。
- 把原有资源文件迁移到CDN里去
原来的外包团队磨磨唧唧六个人大概半年才弄完，定下重构后，三个人一个月搞完了。
总结起来几点：
- 切勿盲目相信外包，即使是前期创业阶段外包也要自己找一个懂技术和架构的人看住外包方。
- 没有重构不了的系统，庞大的淘宝都能重构五遍，何况我们手里的“小”系统。
- 没有调不了的bug，只有调不了的心态。
- 重构一般都是对固定的需求进行代码重写，只要肯下功夫，一定是摧枯拉朽一般的进代码
在代码外寻求帮助
1.搜索引擎或者程序员论坛🎉
百度通常很难解决你的问题，请前往更加专业的程序员论坛来找到解决你问题的办法
- 国内
- 博客园(界面太老旧，内容至上)
- CSDN(有广告,而且优质的内容可能要钱)
- 掘金(主要是前端内容)
- 简书(适合寻找小问题，大篇幅的教程很难在简书上找到)
- 开发者搜索(百度出品,界面简洁,但是因为是搜索引擎而非论坛，所以质量参差不齐)
- 百度
- 在搜索的时候加上参数来过滤一些选项
- 去掉所有的广告
python的数组怎么排序 -advertisement
- 只在指定的网站搜索
site:www.bilibili.com python中logging等级
- 可以组合进行使用达到没有广告的同时也在指定的网站搜索
- gitee(一般是搜源码)
- 开发者社区
- 慕课网
- 51CTO
- InfoQ
- 开源中国
- Segmentfault
- 外国(需要FQ)
2.向身边的同事或者朋友求助:person_frowning:
在你发起提问之前请先遵循提问的艺术，不要问出一些非常基础的问题
下面是提问的艺术的摘要(为适应刚刚入门的萌新所以有稍许修改)
提问之前
在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：
1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件（FAQ）以找到答案。
5. 尝试自己检查或试验以找到答案。
当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为你更乐于回答那些表现出能从答案中学习的人的问题。
- 准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
- 小心别问错了问题。如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着
蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训。 - 另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。
谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。
当你提问时
精确地描述问题并言之有物
- 仔细、清楚地描述你的问题或 Bug 的症状。
- 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：
Fedora Core 4、Slackware 9.1等）。 - 描述在提问前你是怎样去研究和理解这个问题的。
- 描述在提问前为确定问题而采取的诊断步骤。
- 描述最近做过什么可能相关的硬件或软件变更。
- 尽可能地提供一个可以
重现这个问题的可控环境的方法。
话不在多而在精
你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。
这样做的用处至少有三点。
第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加；
第二，简化问题使你更有可能得到有用的答案；
第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。
描述问题症状而非你的猜测
告诉黑客们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。
蠢问题
我在编译内核时接连遇到 SIG11 错误，
我怀疑某条飞线搭在主板的走线上了，这种情况应该怎样检查最好？
聪明问题
我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU（威盛 Apollo VP2 芯片组），
256MB Corsair PC133 SDRAM 内存，在编译内核时，从开机 20 分钟以后就频频产生 SIG11 错误，
但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用，但是关机一晚上就又能工作 20 分钟。
所有内存都换过了，没有效果。相关部分的标准编译记录如下…。
由于以上这点似乎让许多人觉得难以配合，这里有句话可以提醒你：所有的诊断专家都来自密苏里州。 美国国务院的官方座右铭则是：让我看看（出自国会议员 Willard D. Vandiver 在 1899 年时的讲话：我来自一个出产玉米，棉花，牛蒡和民主党人的国家，滔滔雄辩既不能说服我，也不会让我满意。我来自密苏里州，你必须让我看看。） 针对诊断者而言，这并不是一种怀疑，而只是一种真实而有用的需求，以便让他们看到的是与你看到的原始证据尽可能一致的东西，而不是你的猜测与归纳的结论。所以，大方的展示给你看吧！
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。
经常寻求技术帮助的人在心中有个更高层次的目标，而他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。
蠢问题
我怎样才能从某绘图程序的颜色选择器中取得十六进制的 RGB 值？
聪明问题
我正试着用替换一幅图片的色码（color table）成自己选定的色码，我现在知道的唯一方法是编辑每个色码区块（table slot），
但却无法从某绘图程序的颜色选择器取得十六进制的 RGB 值。
第二种提问法比较聪明，你可能得到像是建议采用另一个更合适的工具的回复。
询问有关代码的问题时
别要求他人帮你调试有问题的代码，不提示一下应该从何入手。张贴几百行的代码，然后说一声：它不能工作会让你完全被忽略。只贴几十行代码，然后说一句：在第七行以后，我期待它显示 <x>，但实际出现的是 <y>比较有可能让你得到回应。
最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例（bug-demonstrating test case）。什么是最精简的测试用例？那是问题的缩影；一小个程序片段能刚好展示出程序的异常行为，而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例？如果你知道哪一行或哪一段代码会造成异常的行为，复制下来并加入足够重现这个状况的代码（例如，足以让这段代码能被编译/直译/被应用程序处理）。如果你无法将问题缩减到一个特定区块，就复制一份代码并移除不影响产生问题行为的部分。总之，测试用例越小越好（查看话不在多而在精一节）。
一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。
如果你只是想让别人帮忙审查（Review）一下代码，在信的开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。
了解 BUG 的等级
BUG 也是有等级的，你需要依照严重的等级进行修复
你将错误分级能够更好的让其他人重视你现在的问题，如果你告诉别人你现在有一个错误，这可能不能提起他人的警觉，如果告诉别人你现在有一个最高等级的致命错误，他人或许会放下二郎腿开始重新审视你的错误
优先解决那些可重现的，可重现的bug特别好找，反复调试测试就好了，先把好解决的干掉，这样最节约时间
这些 BUG 等级从高到低分别为
投入时间⏲️
请确保你在正确的错误等级投入正确的时间
-
例如明明有一个1级的致命错误，却修复一个4级的外观错误修复了一整天
-
或者工期就在眼前，却去完善一些都不算 BUG 的细节功能
如果是比较低级的错误，请不要反复的打扰你的同事或者你的领导
1级错误 致命错误 CRITICAL⚠️
特别严重的问题，需要抢修，联系身边在负责的所有同事，需要在最快的时间内维修
- 常规操作引起的程序崩溃
- 例如：QQ只是点击了联系人就直接崩溃了
- 涉及到金钱的计算错误
- 例如：花钱结果钱越花越多
- 数据库泄露或者被攻击，被盗取，用户数据泄露
这一类的 BUG 非常严重，需要和时间争分夺秒，每一分每一秒都有可能增加公司的亏损
2级错误 严重错误 ERROR🔴
这一类的错误需要被重视，如果没有处理好会延时上线，耽误进度，这一类的BUG请联系你的同事，你们需要尽快解决
- 重要的功能无法实现
- 例如：游戏无法进入主页面，网站上线缺根本无法访问
- 错误波及范围非常广泛，影响到了其他重要功能的实现
- 例如：游戏无法识别前进键，微信聊天的时候发送按钮点击了没反应
- 难以接受的外观
- 例如：图片被拉长，密码明文显示，操作有明显卡顿，甚至有的时候控件无法点击
- 非常规操作导致的程序崩溃，用户死机(非常规操作：正常情况下用户使用软件时不会进行的操作)
- 例如：连续不断点击发送按钮一万下，通过聊天框直接发送二进制比特流
这一类的 BUG 比较严重，通常需要多个人进行反复排查和测试，同时还要防止 BUG 复现
3级错误 一般错误 WARNING🔺
这一类的错误不会影响程序的运行，大多都是对操作步骤有较大的缺陷，或者产品的界面非常偏离预期
- 次要功能无法正常实现
- 例如：有一个全选按钮选择后没法全选，但是你依旧可以手动全选
- 操作界面错误
- 例如：本来应该显示人名的标签现在显示了年龄
- 一些重要的操作没有任何提示
- 例如：删除操作，数据错误提示
- 如果是一般功能的提示会成为
4级错误,但是如果这些提示涉及到主要功能的实现，那么这个错误的等级会相应的提升
这一类的 BUG 在最后阶段或者其他空余时间会进行修复，通常不需要多人协同
4级错误 外观错误ℹ️
程序可以运行，但是还能做的更好，这一类的 BUG 可以记录待做列表，但不值得你全力以赴
- 图形界面图标位置偏离期望的位置
- 程序有明显的错别字
- 在一些比较复杂的操作下没有辅助说明，或者提示
- 需要用户进行输入的时候没有告诉用户需要输入什么样的值
这些 BUG 请不要非常着急的找到别人，如果有缺陷软件请提交到缺陷软件上，或者在吃饭的时候在员工餐厅提出
不需要处理的 BUG🚫
这一类的 BUG 不需要修改,可能是多方面的原因，但是你只要放着就好了
- 和产品经理说明后表示不必采取措施
- 产品的设计就是这样
更多建议
写代码的时候请多花一点时间来构思，一个好的代码后期的维护也一定是非常方便的，同时出现错误的可能也大大减小，请尽量做到以下几点
模块化编程
多次重复使用到的方法请尽量打包，高度耦合的方法请拆开分别书写方便后面进行复用，如果有一个非常大的功能需要实现请建立一个类
最小可测试单元
在写代码的时候请保证能有一个最小的可以测试的单元，方便自己和他人也能进行测试
留下测试的数据
每一次测试尽管没有问题也请保留下那些测试的数据，如果以后的报错就能根据之前的文档来找到出错的地方
写模块的时候请写函数注释
在函数注释内写清楚需要传递的值的类型以及规范，例如
def sum_list(number_list):
"""sum_list
这个函数能够把一个数字列表相加
:param number_list: 请输入一个由数字组成的列表
"""
print(sum(number_list))
可以看到你写了函数注释之后，你在IDE中调用的时候就会显示你的函数注释，方便他人的调用和阅读
使用版本控制工具 Git/SVN
你通常无法做到一直向前，有的时候你出错了你希望回到你之前的某一个状态，这个时候你就需要用到 Git，很多刚刚踏入这一行的程序员并不喜欢使用版本控制工具，请尽快习惯这个工具，也许某一天会帮上你的大忙
一些垃圾话
😄程序员不可能永远都不犯错，大家都会遭遇到 BUG ，如果是自己写的 BUG 或许对 BUG 有心理预期，或者有提前准备，这是极好的。
📄但是更多的情况，出现无法解决的 BUG 通常都是其他程序员留下来的，你不能指望其他程序员代码逻辑清晰，或者毫无 BUG，你需要做的就是最快的找到这些 BUG 然后修复他们
📄对于一个改 BUG 的老手，这篇文章或许没有意义，或许内容过于浅薄，但是这篇文章基于我的经验，可以给刚刚接触编程的朋友们留下一个思路，不要毫无目的性的撞大运改 BUG，修改 BUG 也是有一定技巧的
📄花费大量的时间一个 BUG 当然可以修复，但是你希望能够缩减这个时间，让刚刚踏入编程领域的程序员能够把这些时间投入到更有意义的环节中，比如思考整个程序的框架，或者能够继续优化的方案，而不是花费一天时间修改 BUG
📄请不要在不清问题的情况下就将需要实现的功能抛给你的同时，除非你是甲方，或者你为此进行知识付费，如果想要得到一个高质量的免费回复请至少让其他人看到你的努力
结尾
感谢你能看到这个地方，如果你有更多有意思的建议或者其他与众不同的方案，请在聊天框内交流或者私信我，这能帮助大家都更加快速的进步和学习
引用:
如何快速解决程序中的Bug？程序员经验分享
https://www.bilibili.com/video/BV1sb4y1U75Y
Bug有哪些分类和等级？
https://blog.csdn.net/zhou948873316/article/details/112347084
知乎
https://www.zhihu.com/question/23019630/answer/23369396
