读书笔记-软件工程师指南【2-10-2】工具之 CI/CD

下面的内容是我在作为一名程序员入职之前阅读的由Gergely Orosz写的The Software Engineer’s Guidebook。我将将阅读时得到的重要的信息总结成中文以供大家分享。

快速迭代的三种方法

第一种方法是阅读现有的代码并理解其功能。 写代码的挑战通常不是如何编写代码，而是要写什么样的代码。当在一个较为复杂的代码库中工作时，情况尤其如此。当你理解事物如何运作，并且能够熟练地在代码库中导航时，你会更加高效。以下是一些你可以做的事情：

请求有经验的工程师为你解释代码结构。 请一位经验丰富的工程师为你解释代码库的各个部分，各部分的功能以及需要注意的事项。
绘制类/模块及其连接关系。 用手或者像Excalidraw、LucidCharts之类的工具简单绘制一个图表。画出代码库中的各个部分并记录下你对它们角色的理解以及它们连接到什么。
与队友分享你的代码图。 与队友分享你创建的图表并征求反馈；这通常会引发有意义的讨论。经常情况下，你并不是唯一一个可以从图中学到新知识的人；其他人可能会从你的图中找到代码需要改进的地方，或者他们之前没有意识到的关联性。
制定一个备忘单。 记录下关键代码部分的查找位置，以及经常使用的模块或类。这可以很简单，比如一个文本文件或者基本文档。当你有“恍然大悟”的时刻时，记下来。

第二种方法是了解如何调试CI/CD系统。

CI代表“持续集成”，CD代表“持续部署”。在大多数科技公司和初创公司普遍使用CI/CD系统。在工作中，你可能会偶尔遇到CI服务器上意外失败的测试，或者使用CD部署时出现问题。这些问题通常很少见，但很难找到原因。

• 了解你公司和团队的CI/CD工作原理。这种理解会增进你对幕后发生的事情有所了解。哪些脚本运行以及运行顺序是什么？你如何检查设置？向资深或有经验的工程师请教关于该系统的指导。如果有专门维护CI/CD系统的团队，跟他们的一位工程师交流一下。
• 如何访问CI/CD日志？它们对于理解某些构建失败的原因至关重要。是CI/CD基础设施的问题，还是最近代码修改中可能出现的回归问题？

第三种方法是了解如何访问生产环境的日志和仪表板。

在没有关于可能发生了什么的详细信息的情况下，为用户调试生产问题是具有挑战性的。因此，要弄清楚以下几个方面的访问选项：

• 生产日志、仪表板和度量
• 如何为特定用户过滤这些日志
• 如何查询各种相关数据源进行调试
• 如何为特定用户访问崩溃转储、错误和异常
• 调试生产日志时需要遵循的流程。例如，当调试生产数据时涉及到个人信息，可能有数据保护流程需要遵循。向你的经理和更有经验的工程师请教。

如果你有一个生产力备忘单，可以添加相关详情以便日后快速查阅。

在可能的情况下进行小的代码更改

在工作环境中，通常会通过提交拉取请求（PR）来进行代码更改，并附带上一个关于PR的描述。以下是一些有效处理PR的方法：

• 尽量保持拉取请求的小巧。把你的更改分解成每个一个小的PR，每个PR只修改一个事情。
• 总结“为什么”和“做了什么”。在拉取请求中，用不超过几句话解释为什么要做出这个更改。提供一个简短的概述你做了什么更改。记住，PR注释将来会被其他人阅读，了解为什么要进行这个更改。过度解释要比不够解释更有帮助。
• 当UI发生变化时：使用图片。一张图片胜过千言万语。附上一个“之前”和“之后”状态的图片。
• 提及已覆盖和未覆盖的边缘案例。明确表明你考虑了哪些情况。
• 清楚地说明某个更改范围之外的事项，特别是如果未来预计会有后续工作的话。
• 寻求对你拉取请求摘要的反馈。请更有经验的工程师审查你最近几个PR。询问他们喜欢什么，有什么让他们困惑的地方，以及对于撰写更清晰、更简洁摘要的建议。

编写并运行自动化测试

编写代码中最耗时的事情往往是：编写代码。这包括构思方法、编写正确的代码，以及测试代码是否能够正常工作。接着，接下来最耗时的活动是修复你刚编写的代码引起的问题！编写既无错误又不会导致回归的代码的最佳方法是进行测试。当然，你应该在做出更改后手动测试你的代码。然而，也有一种更有效的方式：运行代码库中已经存在的自动化测试，并编写新的自动化测试来测试你的代码，并可捕捉未来的回归。关于为什么测试很重要和常见的方法，我们将在第三部分“测试”中详细介绍。现在，这里是一份你应该熟悉的测试简要摘要：

• 单元测试。 这是大多数环境中测试的基础。假设你的团队已经在使用单元测试，加入他们学习如何编写优秀的测试。从你的团队获得反馈。
• 集成测试、截图测试和端到端测试。 这些测试更复杂，测试功能范围更广。在后端开发中，集成测试可能更相关。对于Web和移动开发，截图测试和端到端测试可能更常见。了解你的团队是否使用这些测试，并学会如何编写和维护它们。

不要只是等待代码审查：主动要求审查

等待太久才能获得代码审查会减慢你的进度。当你提交代码进行审查时，考虑让更有经验的开发人员知道代码审查将有助于你进一步进展。

确定是否以及何时应请求此类审查的最佳方法是询问团队中的其他开发人员：在进行代码阅读时，是否介意你提醒他们进行审查？团队中是否有人宣布审查的渠道？

更有经验的开发人员会明白，提供及时的代码审查对帮助开发人员更快地前进有很大帮助，并会优先考虑这样做。但如果他们还没有这样做，就问问如何最好地让他们知道你需要他们的帮助解决问题，并获得那个必要的审查。

频繁获取反馈

成为可靠的软件工程师的两种最快方式：

• 构建东西：通过编写代码解决问题并将代码部署到生产环境。
• 获取反馈：你的解决方案是否按预期工作？是否没有任何副作用地达到你的预期？

通过部署到生产环境获取反馈。 获得对你的工作的反馈最直接的方式是将其部署到生产环境，然后确认它按预期运行。这种方法的好处在于，如果你的代码有错误或问题，有很大机会从客户那里很快得到反馈。

当然，通过生产环境获得反馈的缺点是可能会出现问题。幸运的是，有更安全的获取反馈的途径可以明智利用。

要求对你的工作进行反馈。 有时，从你信任的同行或经理那里寻求对特定工作的直接反馈更为有效。

寻求反馈的最佳时机是当你完成一个任务或项目时。这时人们将提供最具体、最有帮助的评论。下次完成一项工作时，考虑找一位更有经验的工程师，询问他们认为你做得好的地方以及有待改进之处。

如果你与经理进行一对一的会议，就请他们就特定的工作或项目向你提供直接反馈。如果他们与你的工作关系不是很密切，可能无法立即提供反馈，但他们可以从团队成员那里收集反馈，并与你一起总结。

许多工程师不擅长提供反馈，不是因为他们不在意提供良好的反馈，而是因为他们不知道如何提供具体和可执行的反馈。如果你收到听起来带有判断性，或者不够有帮助的反馈，比如“你本可以做得更快”，或者“你请求了很多帮助”，不要对此抱有个人情感。相反，更深入地探究，将其转化为更具操作性的内容，并询问这些行动是否会解决问题。例如，关于你本可以更快完成某事的反馈可能是个很差的表达方式，意思是你在遇到延迟时没有明确沟通。具有操作性的反馈则是在未来更清晰地沟通障碍。

与队友的成果进行比较。 工作不是竞争，但了解自己在产出和迭代速度方面与同事相比的情况是有益的。观察队友提交拉取请求、将代码推送到生产环境以及完成任务的频率。

目标只是要了解你在团队正常工作速度方面的表现。一旦熟悉完毕，工程师以合理的速度达到他们的水平是标准期望。在从其他人那里获得明确反馈之前，有自己的数据点有助于了解自己的表现。

总结

胜任的软件开发人员在具有一定经验水平的项目中完成任务。在能够可靠地完成明确定义的任务和较小的项目，这些任务需要调用你的技术技能、专业知识和经验中，还有很多可学习的东西。

“实践，实践，实践”是成长的最佳建议。除了构建软件外，加速您专业成长的事项包括：

• 在团队中工作，从其他开发人员学习
• 拥有可以向他们提出问题的导师或伙伴
• 能够与开发人员配对
• 有足够的时间深入研究某种技术
• 在足够长时间内从事项目和任务，以便掌握技术，但可以频繁切换以保持学习

许多开发人员急于爬上职业阶梯的下一层。这是可以理解的，因为头衔具有重要作用，可以获得更好的薪资和更好的职业机会。

然而，在软件开发实践中建立扎实的知识和经验基础；例如，学会如何辨别自己卡住了，如何自己解决问题，并养成持续学习的习惯，这些都需要时间，最终将使你受益终身。如果您继续学习和成长，初级阶段的时间并不是“浪费”的。