大约四年前，我获得了计算机科学学位，并开始了我的软件工程师职业生涯。在这篇文章中，我将分享我一路上学到的一些经验教训。首先总结一下：不要假设非技术问题是最难的先思考，然后编码你要创建的东西比你用来创建它的工具更重要每个角色都同样重要不要假设我是开始我的第一份工作最后，我的第一个项目是长期项目中的一项短期任务。这个项目经历了很多开发周期和很多开发者。它具有庞大而复杂的代码库，并与许多外部服务集成。我的首要任务是修复一些间歇性失败的单元测试。待测代码比较老，是资深开发人员写的。由于UI工作正常，并且QA已经对其进行了彻底测试，我假设问题*肯定*与测试本身有关。我花了将近三天的时间试图修复一个在其他方面都很好的测试方法。当我向我的团队负责人解释为什么修复需要这么长时间时，他给我上了重要的***课。他告诉我：不要因为别人的代码看起来正确就认为它是正确的。这可能是我学到的最重要的一课，它适用于很多场景，而不仅仅是代码相关的领域。一些例子：不要假设仅仅因为你要求某人做某事，他们就会去做。永远记得达成明确的协议。您要求某人检查某事，但还没有收到回复？然后跟进。如果某件事很重要，就值得跟上。不要假设其他人理解您告诉他们的内容，即使他们说他们理解。这是我在进入职业生涯以帮助指导更多初级开发人员时学到的一课。我发现我会快速完成一个指令，然后第二天跟进发现问题开发人员没有任何进展，即使他们当时说他们完全理解需求。相反，您应该要求那个人重复所讨论的内容，以确保他们确实理解了。这段经历不仅适合指导开发者，也适合给BA/QA等解释，不要想当然地认为对方是错的。我发现当自己的代码不起作用时，开发人员往往会责怪他人。您保护自己编写的代码，甚至说服自己不可能犯错。如果QA告诉您他们有问题，那么他们这样做是有原因的。通过打消他们的疑虑，你不会有太大损失，而且他们会比拒绝更感激。非技术问题是最难的。在大学里，所有的问题都是技术性的，要解决的问题无非是弄清楚如何让代码有效地工作。但进入我的职业生涯后，我发现这种情况已经很少见了。确保沟通对于跨多个时区工作的大型团队至关重要。为确保该过程有效，需要对其进行明确记录。确定协助或指导新团队成员的方法。在开发过程中引入新事物时，确保平稳过渡。说服项目管理关注长期的代码健康，而数字看起来会推动当前的议程。这只是您参与项目时会遇到的一些事情。在我看来，这些问题比追踪困扰您的空指针要难得多。先思考，后编码您发现了一个可以改进的过程。您立即决定将其自动化。您将所有的空闲时间用于开发可以彻底改变团队工作方式的东西。听起来很熟悉，对吧？包括我在内的开发人员都喜欢自动化解决方案。我的教训是什么？不要只是写代码。停下来思考问题，而不是解决方案。与更广泛的人交谈，而不仅仅是开发人员。首先弄清楚这是技术问题还是工艺问题。然后寻找解决方案。当然，使用Docker和已经编写好的黑客脚本构建一些复杂的解决方案确实很酷，你也可能学到很多东西，但是针对非技术问题提出技术解决方案可能对团队的长期工作没有帮助。这可以掩盖更大的问题。你创造的东西比你用来创造它的工具更重要。当我刚毕业时，我非常热衷于编写代码、学习新的语言和框架，以及任何涉及技术元素的事情。不要误会我的意思，我仍然喜欢它。然而，我后来意识到，只要我们开发人员使用该工具来完成工作，工具是什么并不重要。在前端开发中，每隔几天就有一个新的框架。虽然开发人员跟上这些发展很重要，但最终用户（重要的人）并不关心事情是如何工作的，只要它们能工作就行。每个角色都同等重要我已经提到了不要自动假设非开发人员是错误的重要性。除此之外，我还了解到组成团队的每个成员（BA、QA、PM、其他利益相关者等）与所有开发人员一样重要。一个项目没有每个角色的努力就没有成果；同样，如果不同类型的资源之间不平等地共享资源，项目也不会取得成果。我还了解到，即使实际代码是由开发人员编写的，如果没有利益相关者，代码也没有价值，如果没有代码完成工作的质量保证，就没有利益相关者。结论希望您从这些课程中学到了一些东西。您在职业生涯中获得了哪些有用的经验，不妨与我们分享！原文链接：https://medium.freecodecamp.org/five-important-lessons-from-four-years-as-a-software-developer-9b367f256226【本文为专栏组织《机器之心》原文翻译》，微信公众号《机器之心（id：almosthuman2014）》】点此阅读作者更多好文
