日常生活：前端开发人员如何解决“简单”的 bug

最近我一直在与初级前端开发人员合作，同时也在指导有抱负的开发人员。他们问我的一个问题是如何成为一名更优秀/更资深的开发人员。这个问题我很难量化地回答，但我了解高级开发人员的一个特质是他们能够及时解决问题。在这篇文章中，我想阐述这一点，同时也想通过一些轶事来了解前端开发人员的日常生活，以及解决一个看似简单的问题可能需要经历的曲折。

漏洞

我为我们的一个应用程序实现了一个新的报告页面，用户可以通过设置一些参数来创建类似电子表格的报告。之所以说是类似电子表格，是因为虽然它在用户看来看起来像电子表格，但我将其实现为基于弹性框的独立网格，因为其他要求使得使用常规表格难以实现。到目前为止一切都很好，除了为了保持表格的外观，我确实需要各个网格之间像素级的完美一致性，在对填充和边距进行了一些调整后，我在 Macbook 上的 Chrome 上实现了这一点。代码已部署，一切看起来都很好，除了我的同事在 Windows 上运行时，他们观察到某些列略有偏移，破坏了表格的视觉效果。为了让您了解，这是他们观察到的情况：

很简单，那天早上 8:30 左右我告诉自己，这只是另一个渲染问题，我只需要重现它并修复它。

教训一：“它在我的机器上能用”永远不应该成为开发者对 bug 的有效回答。除非你认为其他人是在妄想，否则你应该以此为基础，至少知道它在某个地方能用。从你的角度来看，这永远不应该是问题的结束。

在 Chrome/Mac 上重现该问题

就像我说的，我的同事在 Windows 10 上确实遇到了这个 bug，所以我首先尝试更改 Chrome 浏览器的分辨率，看看是否与响应问题有关，但显然没有。接下来，我把注意力转移到操作系统上，并认为这个问题可能与 Chrome 渲染在不同操作系统上的差异有关。

使用 BrowserStack 在 Chrome/Windows 10 上重现该问题

接下来，我在 Windows 10 的 BrowserStack 实例上尝试在 Chrome 中运行。试了好几次，还是不行。我们试试别的办法。我突然想起我有个 IE11/Windows 10 虚拟机，用来运行我的 Edge（非 Chrome）。这时，加上站立会议，已经是下午 12 点左右了。

使用 VirtualBox 在 Chrome/Windows 10 上重现该问题

我启动了虚拟机，尝试重现问题，但仍然没有成功。我进一步询问了同事，发现问题与分辨率有关。他们的笔记本电脑分辨率是 1920x1280，所以很容易就能重现这个问题。接下来的一个小时左右，我尝试让 VirtualBox 以相同的分辨率渲染我的 Windows 10 虚拟机，但毫无效果。后来我在谷歌搜索时，有人提到使用 Parallels，而我已经安装了 Parallels。

使用 Parallels 在 Chrome/Windows 10 上重现该问题

在 Parallels 启动后，我很快就能以正确的分辨率启动 Windows 10 VM，安装 Chrome，这让我想到了我最喜欢的对 Windows 同事的讽刺之一

瞧，访问我们的开发服务器后，页面加载后，这个错误就出现了。经过快速调试，我找到了渲染问题的根源。

第二课：善于接受何时放弃。如果你走的路行不通，学会快速重新评估，并尝试一些不同的方法，这样才能更接近你的目标。

问题

在定义特定网格的边框之一时，我使用了以下代码：

border-top: dashed

在 Chrome Mac 上，这实际上翻译为：

border-top: dashed 3px;

基本上默认会创建一个 3px 的虚线边框。我天真地以为这是 Chrome 的默认边框。我发现在 Windows 系统中，让 Chrome 自行决定实际渲染效果如下：

border-top: dashed 1px;

所以网格之间总是存在 2px 的差异。很简单，既然我知道了问题所在，我就想切换回本地环境来修复和测试这个问题。当时大约是下午 3 点。

课程 3：使用 CSS 创建规则时要尽可能具体，不要想当然。

修复

再次尝试修复时，我又遇到了另一个问题。我们的 Angular 应用运行在 4200 端口，而 API 运行在 8080 端口，这意味着即使我将 Parallels 设置为能够从我的 Windows 虚拟机访问我的 Mac 本地主机，我仍然无法启动该应用，因为 CORS 问题。有很多不同的方法可以解决这个问题，我快速尝试了一下：

• 编辑我的/etc/hosts
• 恩格罗克

但我决定使用 Angular 内置的代理配置，我们之前用过，但在 API 上启用 CORS 后就放弃了。我原以为只需要 1 分钟，结果却花了一个小时才发现代理配置根本没用！

Angular 代理

我定义不同的 api 代理路径如下proxy.conf.json：

 "/api": {
    "target": "http://localhost:8080/api",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

例如，当应用程序运行时，尝试访问 ，结果/api/reports会代理到http://localhost:8080/api而不是http://localhost:8080/api/reports。这是什么鬼？重读了好几遍文档后，我终于明白自己做错了什么。Angular/Webpack-dev-server 的开发者们会正确地指出 .ytarget是错的，我不应该在 url 中添加上下文路径，target而应该只添加 host。将配置改为：

 "/api": {
    "target": "http://localhost:8080",
    "secure": false,
    "logLevel": "debug",
    "changeOrigin": true
  },

一切又恢复正常了，我终于可以继续工作并妥善修复问题了。真是太棒了！与此同时，一位初级开发人员提交了一个 PR，我必须对其进行代码审查，这促使我进行了一次视频通话，深入探讨了代码影响，因为这位开发人员并不知道，他代码的实现会引入一些回归错误。解决了这个问题后，我终于可以回到问题上进行修复和部署了，现在大约是下午 5 点。

经验教训 4：关注细节，尤其是语法和拼写。正因如此，结对编程和代码审查等实践才至关重要。让别人帮你检查代码，有助于发现一些小错误，因为我们习惯了自己的代码，所以花了很长时间才发现。

概括

一个看似简单的 CSS 可视化 bug，却引发了一场涉及 Google、VirtualBox 和 Parallels Desktop VM、Browserstack、Angular 以及一些高级网络技术的探索之旅（etc/hosts）。在这个过程中，我学到了一些东西，以下是我从那一天的经历中总结出的一些建议，希望能与有志于前端开发者的朋友们分享：

• 谁告诉你，作为一名前端开发人员，你只需要处理 HTML、CSS 和 JavaScript，那绝对是在撒谎。正如你所见，开发应用程序需要掌握的知识远比你想象的要多，而这些知识通常无法直接传授。你需要通过实践积累经验。
• 作为一名开发人员，你最需要培养的技能就是解决问题的能力。正如本文所述，解决代码问题有时并非易事。你必须在问题中解决问题。
• 对你的工作负责。你最终要对你编写的代码负责，并且你有责任确保它达到最高质量。
• 拥抱过程。这正是我们这个行业如此有趣却又如此令人沮丧的原因。即使你自认为一切都正确无误，事情也并不总是顺利。即使你尽了最大努力，事情也难免会出问题或失灵，而你的工作之一就是想办法让它们重新运转起来。
• 对于团队中的非编码人员来说，重要的是要理解，看起来“简单”的事情可能并不那么简单，无论是在实施过程中，还是在估算时进行纠正。
• 对于我那些非英语的朋友，请提高你的英语水平。就像我说的，解决这些问题需要大量的谷歌搜索，我无法想象如果我的英语不够流利，我的进度会慢多少。网上有很多有用的信息，而且绝大多数都是英文的，所以掌握好英语肯定很有帮助。

现在回想起来，我又回到了 BrowserStack，它似乎可以启动一个特定分辨率的虚拟机，如果我当时留意的话，也许可以节省我几个小时。最终，我觉得整个体验很有趣，但并非个例，而且我从中学到了很多东西。这就是为什么我想与其他人分享它，尤其是那些正在应对冒名顶替综合症的初级开发人员，告诉你们，资深并不意味着无所不知、完美无缺，它只是意味着你会“有型地犯错”，并且通常能够更快地从这些错误中恢复过来。那你呢？你有什么有趣的 bug 或经验可以分享吗？