专业软件开发的一年

专业软件开发的一年

我在专业软件开发领域工作了一年，活了下来——好极了！

我觉得回顾一下自己一年前刚完成一年计算机科学转换项目后，投身软件工程领域的个人经历或许会有些价值。我很幸运，毕业后就被我之前实习的公司录用了，从那以后，我的职业道路漫长而曲折。

我觉得有几点值得分享，希望新入行的人能够在心态上有所保障，并了解如何在未来的工作中不断进步和适应。以下是我在过去一年中学到的关键经验：

征求同事的意见和建议

这看起来很明显，但是与各种各样的开发人员合作过，从典型的摇滚明星开发人员（他们在一夜之间弹出服务和存储库而没有任何测试覆盖率）到对某些生产代码的单行 PR 更改提供痛苦反馈的开发人员，重要的是您要权衡同事的意见和您自己的意见。

当你还是一名新开发者时，大家似乎都经验丰富，但随着你接触代码库和不同人工作流程的次数增多，你开始发现，有些开发者为公司/团队提供了真正的价值，而有些开发者则只是在为自身利益而大量编写代码，无论他们的目的仅仅是推出一项服务，还是试图在某个季度或冲刺阶段强调自己独特的贡献。这两种人的经验都能给你带来启发，并帮助你更好地适应个人发展和工作流程。

你们以团队的形式进行编码。而不是以个人的形式。

过去一年，我曾在多个团队工作过，发现团队合作对于实现目标至关重要。（当然）。我发现，那些花时间规划季度或冲刺阶段，并准确考虑成员技能和才能的团队，更有能力精准地确定工作范围，并营造出积极的工作氛围。

作为一名新晋开发者，你需要高度依赖同事的支持。在你能够做出有意义的贡献之前，不可避免地需要一段时间的积累，但重要的是要意识到你的同事有责任帮助你，而你不应该羞于或羞于提出请求。正如他们为你提供支持一样，你也应该能够为未来加入的新开发者提供进一步的支持。

这是一个弱肉强食的世界，我们开发者必须团结一致。说到团队协作……

定期编写测试并维护文档

为了您自己和同事的理智，如果可以避免，请不要在生产中测试代码。

您需要确保提交的代码符合一定的生产质量标准，并具有高水平的测试覆盖率和完善的文档。这样做有很多好处：

• 任何未来可能影响您代码库的变更，在测试失败时都会立即被拾取。如果服务在一夜之间突然出现，且测试覆盖范围有限，并在之后投入生产，您，甚至更糟的是，您的团队成员，将不得不承担日后出现问题时实施测试的技术债务。

• 高质量的文档使代码库更容易理解如何在本地、在生产中部署服务，或者只是提供有关您的应用程序是什么以及如何测试其功能的见解。

• 团队协作。如果您是新开发人员，了解经过质量测试和良好文档的代码库将对您大有裨益。您应该将自己的工作成果提升到新开发人员可以轻松掌握和使用的标准视为一项责任。这并不是说您的代码应该始终简洁，而是要注意一些基本事项，例如使用描述性变量名以及详细的本地/生产部署说明。

要理解你的代码，你需要能够编写测试。我坦白承认，我有时会为此感到困惑，因为通常情况下，直接编写一段代码比模拟服务器调用来测试更容易。在工作中，一定要参考测试三角。

让工作流程为您服务

无论您的团队采用的是敏捷看板、Scrum 还是瀑布式开发方式，关键在于专注于让现有系统发挥您的优势。软件开发有很多工作方法，但我见过最常见的方法是使用看板（Jira、Trello、LeanKit），并针对史诗、故事、任务、错误以及如何单独处理它们制定特定的规则。

学习现有的系统，学习如何编写各种工单，学习如何利用现有的系统来优化你的工作流程。如果有一个简化的记录和处理错误的流程，一定要遵循这个流程。我绝不会建议盲目地将现有的系统视为最佳，你绝对应该在每个环节都质疑你的团队或更大的组织目前实施的特定“工作方式”是否合理。

在处理诸如站立会议、改进、计划、回顾、事后分析等例行事务时，请调整并使用对团队成员最合理的流程。如果团队成员无法从中获益，那么每天的站立会议就毫无意义。同样，如果发现计划耗时过长或价值不高，请提出问题并提供替代方案，尝试解决遇到的问题。

永远不要随波逐流，尤其是当这种趋势不利于团队生产力时。

接受好的坏的

软件开发本质上就是一条坎坷之路，充满着高峰和低谷。我有过很多这样的经历：一段代码运行不符合预期，我绞尽脑汁想了好几个小时才发现变量名中有一个拼写错误。我也遇到过类似的问题，用 Postgres 数据库查询时，本来应该只是一个简单的 order by 查询，结果却得到了奇怪的结果，最后才发现我使用的 JS 库也有自己的问题。甚至有几次，我尝试应用大学里学到的东西，比如使用 xmlhttp 请求，却发现在 React 中，直接用 axios 库做同样的工作要快得多。更别提过去一年里我不得不调试的 CORS 相关问题的数量了……

这些经历只是我一路走来遇到的少数个人经历，它们当时都让我感到很为难，但从每一次经历中，我都学到了很多，并调整了我自己的个人调试方法。如果你还没听说过，你应该去看看《Rubber Duck Debugging》。

但软件工程的核心在于解决问题。作为一名初级开发人员，如果不犯错，就无法学习。重要的是，只在需要时才尝试寻求帮助。在向资深开发人员——那些“解谜大师”寻求建议之前，不要害怕直面问题。你不会因为获得答案而变得更擅长解谜，而是通过接触这些谜题并调整你的思维来寻找解决方案，从而变得更好。

初级和高级之间的差异并没有那么大……

我的观点是，毕业的开发者们总是很快给自己贴上“初级”的标签，尽管他们可能已经花了长达 4 年时间从事独立项目或学习大学相关知识。尽量不要把自己当成初级开发者，而应该专注于如何成为一名更优秀的开发者。

我发现“初级”和“高级”开发人员之间除了经验之外最大的区别在于解决问题的视角。高级工程师在遇到 bug 时会坚持不懈，并运用他们丰富的知识（例如高级的 Google/Stack Overflow 技能）不断探索各种问题的解决方案。

想象一下这样的场景：你遇到了一个 bug，无法让那个 API 正常工作，你尝试了好几天，却始终无法理解。最终你屈服了，向一位高级开发人员寻求帮助。他们只是离开几分钟去检查一下，然后回来像变魔术一样，在不到 10 分钟的时间内解决了你的问题。你完全可以肯定，他们之所以能够修复这个问题，是因为他们之前遇到过这个问题，记得在谷歌上搜索过，并根据结果 #3 解决了它。

我并不是一概而论地说所有情况都是如此，开发人员不应该过度依赖这些资源，但始终要考虑到，高级开发人员不一定知道所有答案，但他们知道如何以不同于你的方式调试或寻找解决方案。在结对编程期间与同事坐在一起，观察他们采用的调试错误代码的方法，是非常宝贵的经验。这些调试技能将是你能获得的最宝贵的技能之一。

最令人惊讶的事情……

当你还是一名初出茅庐的大学毕业生时，你很快就会接触到一些在职业发展领域可能意想不到的事情。以下是一些让我感到意外的点，你可能需要注意：

• 即使是最简单的项目，你也会处理庞大的代码库。花点时间去理解新的代码库——尽量不要被一些项目的规模吓到，因为它们可能与你在大学里处理过的项目规模不同。

• 最简单的任务通常比你最初预期的要耗时更长。我仍然经常为给技术工单分配准确的故事点而苦恼。估算完成一项任务所需的时间需要时间和经验的积累。

• 外部依赖关系是处理起来最令人头疼的事情之一。无论是依赖其他团队启动并运行 X 服务，还是在实施变更之前合并 Y PR……永远不要低估依赖外部团队或你无法直接控制的资源所带来的额外复杂性。

• 不同的开发者对文档和 PR 等内容持有不同的标准。我尝试遵循的关键建议之一是保持一致。无论 PR 的大小，我都会花时间添加简短的描述、将其链接到某个问题、插入修改内容以及标记 PR 是否已准备好进行审核。虽然这可能需要一些额外的时间，但即使是这些基本事项，保持一致和清晰也是值得的。

• 你会感觉要花上一生的时间去等待持续流水线、代码编译以及许多其他有趣的过程的完成。关键在于仔细规划你的时间，避免这些潜在的时间浪费。

• Git 可能非常苛刻。熟悉使用 Git 进行一些操作，例如对提交进行变基，以整理你的 PR，这样你就不会有冗长的提交历史链，包含重复的提交信息或更糟糕的情况。花时间阅读 Git 文档，练习跨分支工作和变基提交也非常值得。掌握 git stash 和 git stash pop 等命令也非常有用。

• 比较可能会有害。尽量不要将你每周的产出与更有经验的同事进行比较。试图跟上最优秀的人的步伐是很自然的事情，但刚开始的时候你需要接受你可能需要以稍慢的速度工作，这完全没问题。开发人员将他们的一些知识视为理所当然，在传递工作时，他们常常会忘记他们已经做过 101 次的事情在前 4 或 5 次实际上相当棘手。除非你能够表达出来，否则人们不会知道你的局限性。这可能很棘手，具体取决于你的工作环境，但如果你所在的公司有理解你的同事和积极的工作氛围，你应该可以自由地大声喊出你无法在规定时间内完成任务，或者你可能需要一些关于某项任务的结对编程方面的帮助。

• 你在大学里学到的东西虽然有用，但还不到你在工作中可能用到的一半。就我个人而言，我从未接触过 Docker 和 Kubernetes、持续集成流水线、构建工具等技术，甚至在某些情况下，我最终在项目中采用的语言，包括 React/JavaScript 和 Scala/Play/Akka，我都没接触过。

• 技术确实瞬息万变。你很可能会在很短的时间内体验各种语言、技术栈、部署服务、数据库以及许多其他资源。在科技行业工作就像是一段持续不断的大学式经历，技能提升对你的职业生涯至关重要。你可能已经毕业并开始了一份新工作，但真正的学习经历才刚刚开始。

结束语

我非常感激有机会转行到科技行业，接触并了解如此多不同的技术。我非常幸运，拥有优秀的同事和绝佳的工作环境，让我有足够的空间提升自己的技能。如果我说这段经历轻松顺利，那绝对是在撒谎——在科技行业工作确实充满挑战，但乐趣也正在于此。如果一帆风顺，那就会很无聊。

我认为，对于许多即将进入专业软件工程领域的毕业生来说，工作的第一年将是最艰难的一年。我的建议是不断提问，尽可能多地寻找导师，不断寻求反馈，并坚持完成自己的个人项目。依靠在线课程和偶尔枯燥的讲师来提升技能有时会很枯燥，但没有什么能比得上构建自己的端到端应用程序并将其部署到AWS/Heroku/Firebase或任何其他你可以访问的服务上所带来的刺激和体验。

我希望这里的知识能够帮助其他即将进入专业软件开发领域的人。我很乐意听取其他即将入行一年的开发者的经验，并听取你们的反馈。如果您有任何建议或经验想与社区分享，欢迎在下方留言。

非常感谢你的阅读。
下次再见！