初入软件「江湖」的萌新需要了解的五个经验教训

大概四年前我获得了计算机科学学位并开启了软件工程师的职业生涯。我将在这篇文章中分享一些我这一路过来学习到的经验教训。先归纳一下：

• 不要假设

• 非技术问题才是最困难的

• 先思考，再写代码

• 你要创造的东西比用于创造它的工具更重要

• 每个角色都同等重要

  不要假设

在我开始第一份工作后，我的第一个项目是一项长期运行的项目中一个短期任务。这个项目已经经历过很多开发周期和很多开发者。它有很大很复杂的代码库，而且整合了很多外部服务。

我的第一个任务是修复一些会间歇性故障的单元测试。要测试的代码相对老旧，是一位资深开发者曾经编写的。因为从 UI 看其功能效果良好，并且 QA 也彻底地测试过它，所以我就假设问题肯定和测试本身有关。

我花了近三天时间想要修复本来没有问题的测试方法。当我向我的团队领导解释修复工作耗费如此长时间的原因时，他教给了我重要的第一课。他告诉我说：不要只是因为别人的代码看起来像是正确的就假设它确实正确。

这可能是我学到的最重要的教训，而且这一教训可应用于很多场景，而不仅是代码相关领域。举些例子：

• 不要只是因为你叫过某人去做某些事就假设他确实会做。永远记得要达成明确的一致。你让某人去检查某些东西但还未得到答复？那就去跟进一下。如果某些事情是重要的，那就值得保持跟进。

• 不要假设别人理解你告诉他们的内容，即使他们说自己确实理解。这个教训是我的职业生涯进入到帮助指导更多初级开发者时所学到的。我发现我会快速说完指令，然后第二天跟进时却发现相关的开发者没什么进展，即使当时他们说过已经完美地理解了需求。相反，你应该让那个人复述一遍讨论过的内容，这样你才能确保他们确实理解了。这个经验不仅适用于指导开发者，也可用于向 BA/QA 解释等等。

• 不要假设对方是错的。我发现开发者在自己的代码无效时往往倾向于责备他人。你对你写的代码有保护欲，甚至会达到说服自己相信不可能出错的程度。如果 QA 告诉你他们遇到了一个问题，他们有理由这么做。消除他们的疑虑不会给你太多损失，而且比起被拒绝，他们也会更加感激。

  非技术问题才是最困难的

在大学里时，所有的问题都是技术方面的，要解决的问题不过就是想办法让代码有效工作。但是进入职业生涯后，我发现情况很少再会是这样了。

对于一个跨多个时区工作的大型团队而言，确保沟通至关重要。要确保流程有效，要有清楚的文档记录。要确定提供帮助或指导新团队成员的方法。为开发过程引入新东西时，要确保平滑过渡。当数据数字着眼于推动当前的议程时，要说服项目管理注重长期的代码健康。

这只是你在参与项目时会遇到的一部分事情。在我看来，比起追踪困扰你的空指针，这些问题可要难多了。

先思考，再写代码

你发现了一个可以改进的流程。你立马决定将其自动化。你投入了所有的空闲时间开发能完全改变你的团队的工作方式的东西。

听起来很熟悉，对吧？包括我在内，开发者都热爱自动化解决方案。

我的经验教训是什么？不要直接写代码。停下来想想问题，而不是解决方案。和更广泛的人交谈一下，而不只是开发者。首先搞清楚这究竟是一个技术问题还是一个流程问题。然后再寻找解决方案。

当然，使用 Docker 和已写好的完美脚本构建一些复杂的解决方案确实很炫酷，而且你可能也能学到很多，但为非技术问题提出技术解决方案可能无助于团队的长期工作。这可能掩盖更大的问题。

你要创造的东西比用于创造它的工具更重要

我刚毕业时非常热爱写代码、学习新语言和框架以及任何涉及到技术元素的东西。

不要误会，我现在依然热爱。但是，我后来意识到，只要我们开发者使用的工具能让我们完成工作，那么工具究竟是什么其实不重要。在前端开发中，每隔几天就会有一种新框架。尽管开发者跟进这些进展很重要，但最终用户（重要的人）并不在乎工作原理，只要有效就行。

每个角色都同等重要

我已经提到了不要自动假设非开发者是错误的的重要性。除那之外，我也学习到构成你团队的每个成员（BA、QA、项目经理、其他利益相关者等等）都和所有开发者一样重要。

如果没有每个角色的努力，项目是不会有成果的；类似地，如果不在各种资源类型之间平等地共享资源，项目也不会有成效。

我还学习到，即使确实是开发者写出了实际的代码，但如果没有利益相关者，代码就没有价值；而如果不能在质量上保证这些代码能完成工作，也不会有利益相关者。

总结

希望你能从这些经验教训中学到些东西。你在职业生涯中收获了哪些有用的经验，不妨也与我们分享！

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: