473. 步伐猿之办理问题

程序员 · 2024-10-3 22:42:25

作为一个软件开发工程师，常常会遇到各种bug需要修复。
一样寻常来说，本身写的的代码，测试工程师形貌一下问题的征象（比如网站某个页面打不开了），开发工程师就知道大概是什么地方出了问题（这种环境很有大概就是已知的缺陷）。
但随着软件系统的不停扩大，代码复杂度会越来越高，这时间单单靠形貌问题征象是很难明决问题的了，纵然是本身写的代码，这时间也需要测试工程师给出详细的复现步调，开发工程师通过复现步调，能大概知道堕落代码的位置，修复完，扔给测试查抄有没问题即可。
遇到更复杂的bug，测试工程师给出了复现步调，开发工程师就只能定位到代码的大概位置，但照旧很疑惑——究竟什么地方堕落了？这时间，一样寻常是开发工程师的技能缺陷。比如说：有一段给字符串去除空格的代码。测试工程师反馈代码有问题，输入一串字符之后，输出的字符里头另有空缺占位符。遇到这种环境，就需要将详细的报错出如今开发工程师的开发呆板上，让开发工程师知道详细是哪一行出的错误，错误的上下文（即相干变量的值）是什么。到达这一步，问题开发工程师就名顿开：哦哦，原来空缺字符出了“空格”另有“TAB键”等等七零八落的玩意。
遇到更复杂的环境，比如说是大型分布式数据库环境，开发工程师无法复现问题，这时间就需要有详细的报错日记里的报错信息（报错信息中一样寻常会有报错提示、报错堆栈）（实在上一段里头，开发工程师想知道的也是报错堆栈，只不外这一段里形貌的是报错堆栈难以获取的环境）。这时间依赖于bug陈诉职员的日记分析本领了，从各个服务的日记文件中，定位堕落误，并提取错误堆栈给开发工程师，这里就考验bug陈诉职员的 linux 下令的功底了。

473. 步伐猿之办理问题

所属分类: 问答交流

新帖推荐: 30日

推荐作品