经验教训 软件开发

by Stephen McLean

斯蒂芬·麦克林(Stephen McLean)

作为软件开发人员四年来的五个重要教训 (Five important lessons from four years as a software developer)

It’s been almost four years since I graduated with a degree in CS and began my career as a Software Developer. In this post, I’d like to share some of the lessons I have learned along the way.

目录 (Table of Contents)

• Never Assume

  永不承担

• The non-technical problems are the most difficult

  非技术问题是最困难的

• Think first, code later

  先思考，再编码

• What you create is more important than the tools used to create it

  您创建的内容比用于创建它的工具更重要

• Every role is equally important

  每个角色都同等重要

• Conclusion

  结论

永不承担 (Never Assume)

After starting my first job, my first project was a short-term assignment on a long-running project. The project had seen many sprints and many developers. The codebase was large, complex, and with many integrations to external services.

开始我的第一份工作后，我的第一个项目是长期运行项目的短期任务。 该项目经历了许多冲刺和许多开发人员。 该代码库很大，很复杂，并且与外部服务进行了许多集成。

My first task was to fix some unit tests that were failing intermittently. The code being tested was relatively old and had been written by a senior developer. Since the functionality worked fine from the UI and had been tested thoroughly by QA, I made the assumption that the issue must be with the tests themselves.

我的首要任务是修复一些间歇性失败的单元测试。 被测试的代码相对较旧，并且是由高级开发人员编写的。 由于该功能可以从UI正常工作，并且已经过QA全面测试，因此我假设问题必须出在测试本身上。

I spent nearly three days trying to fix tests that weren’t broken. When I explained to my team lead why the fix had taken so long, he taught me my first major lesson. He told me to never assume that someone else’s code is correct just because it looks like it.

我花了近三天的时间来修复未损坏的测试。 当我向团队负责人解释为什么修复需要这么长时间时，他教了我第一堂主要课程。 他告诉我永远不要仅仅因为看起来像别人的代码就是正确的。

It’s probably the most important lesson I have learned and can be applied to many situations, not just involving code. Here are a few:

这可能是我学到的最重要的一课，可以应用于很多情况，而不仅涉及代码。 这里有一些：

1. Never assume that someone will do something just because you’ve asked them to. Always get an explicit agreement. Haven’t received a reply from someone you asked to check somethingend a follow-up. If something is important, it’s important enough to follow-up on.

   永远不要仅仅因为你要求别人做某事就认为别人会做某事 。 始终获得明确的协议。 还没有收到您要求检查的人的答复吗送跟进。 如果有什么重要的事情，那就足够重要了。

2. Never assume someone understands what you’ve told them, even if they say they do. This is one I learned after progressing in my career to the point where I was helping to mentor more junior developers. I found that I would rifle through instructions, and follow up the next day to find the developer in question hadn’t made much progress even though they had said they understood perfectly what was required. Instead, get the person to give you a walkthrough of what’s been discussed so you can be certain they understand. This applies to more than just mentoring developers, such as explaining something to BA’s/QA’s etc.

   即使别人说了，也永远不要以为别人知道你对他们说的话。 这是我在职业生涯中发展到可以帮助指导更多初级开发人员的知识。 我发现我会仔细阅读说明，并在第二天跟进以寻找有问题的开发人员，尽管他们说他们完全理解所需的内容，但是并没有取得太大进展。 相反，请该人员向您介绍所讨论的内容，以便您可以确定他们是否理解。 这不仅适用于指导开发人员，例如向BA / QA进行解释等。

3. Never assume the other party is wrong. I think developers have a tendency to blame everyone else for their code not working. You become protective over the code you write, to the point where you are convinced it can’t be wrong. If QA tells you they’ve run into an issue, they have a reason for doing so. It won’t cost you much to give them the benefit of the doubt, and they’ll appreciate it more than being shut down.

   永远不要以为对方是错的。 我认为开发人员倾向于责怪其他所有人，因为他们的代码无法正常工作。 您可以保护自己编写的代码，以至于确信它不会出错。 如果质量检查人员告诉您他们遇到了问题，则有这样做的理由。 让他们从怀疑中获得好处并不会花费太多，而且与被关闭相比，他们将不胜感激。

非技术问题是最困难的 (The non-technical problems are the most difficult)

In college all of the problems were technical. Figuring out how to make a piece of code work was almost always the issue at hand. In professional life, however, I have found that that’s rarely the case.

在大学里，所有问题都是技术问题。 弄清楚如何使一段代码起作用几乎总是手头的问题。 但是，在职业生涯中，我发现情况并非如此。

Ensuring communication is clear on a large team working across multiple time-zones. Ensuring processes work, and are clearly documented. Figuring out how to help on-board or mentor new team members. Trying to smoothly introduce something new to the development process. Convincing project management to focus on long term code health when the numbers are pressing their agenda in the present.

确保跨多个时区工作的大型团队的沟通很明确。 确保流程正常运行，并有明确记录。 弄清楚如何帮助新成员或团队成员。 试图平稳地为开发过程引入一些新东西。 在当前数量紧迫其议程时，应说服项目管理将重点放在长期代码健康上。

These are just a handful of examples showing the kinds of things you can run into on a project. In my opinion, they are infinitely more difficult than tracking down that null-pointer that’s been troubling you.

这些只是少数几个示例，它们显示了您可以在项目中运行的各种类型的东西。 在我看来，它们比追踪一直困扰您的空指针要困难得多。

先思考，再编码 (Think first, code later)

You spot a process that can be improved. You immediately decide to automate it. You spend every spare hour developing something that will completely change the way your team works.

您发现可以改进的过程。 您立即决定使其自动化。 您会在每个业余时间花一些时间开发一些可以完全改变您团队工作方式的东西。

Sounds familiar, rightevelopers, myself included, love automated solutions.

听起来很熟悉，对吧发人员(包括我自己) 喜欢自动化解决方案。

What have I learnedon’t immediately go for the code. Stop, and think about the problem, not the solution. Talk to a range of people, not just developers. Figure out if the problem is a technical problem or a process problem first. Then you can figure out the solution.

我学到了什么要立即获取代码。 停下来，思考问题，而不是解决方案。 与各种各样的人交谈，而不仅仅是开发人员。 首先找出问题是技??术问题还是过程问题。 然后，您可以找出解决方案。

Sure, coming up with some intricate solution using Docker and perfectly written scripts would be cool, and you’d probably learn a good deal, but proposing a technical solution for a non-technical problem probably won’t help the team in the long run. It might just mask the bigger problem.

当然，使用Docker和完美编写的脚本提出一些复杂的解决方案是很酷的，您可能会学到很多东西，但是从长远来看，提出针对非技术性问题的技术解决方案可能对团队没有帮助。 它可能只是掩盖了更大的问题。

您创建的内容比用于创建它的工具更重要 (What you create is more important than the tools used to create it)

When I graduated I loved writing code, learning new languages and frameworks, and anything that involved a technical element.

毕业后，我喜欢编写代码，学习新的语言和框架以及任何涉及技术要素的内容。

Don’t get me wrong, I still do. But, I have come to realize that as long as the tools we use as developers enable us to get our job done, it doesn’t matter what those tools are. In front-end development, there is a new framework every other day. And while it’s important as a developer to keep up, the end users (the important people), don’t care how something works, just that it does.

不要误会我的意思，我还是会的。 但是，我已经意识到，只要我们作为开发人员使用的工具能够使我们完成工作，那么这些工具是什么都没有关系。 在前端开发中，每隔一天就会有一个新框架。 尽管保持开发人员的发展水平很重要，但最终用户(重要人员)却不在乎某件事情是如何工作的，只是它确实在起作用。

每个角色都同等重要 (Every role is equally important)

I have already mentioned the importance of not automatically assuming that everyone who isn’t a developer is wrong. As well as that, I have learned that each member that makes up your team (BA, QA, project manager, other stakeholders, and so on) is just as important as any developer.

我已经提到了不要自动假设不是开发人员的每个人都是错误的重要性。 不仅如此，我了解到，组成团队的每个成员(BA，QA，项目经理，其他利益相关者等)与任何开发人员一样重要。

A project doesn’t work without representation from each role and similarly doesn’t work if resourcing isn’t shared equally amongst the different resource types.

没有每个角色的代表，项目就无法运作，而且如果在不同资源类型之间资源分配不均等，项目也将无法运作。

I have learned that even though it’s the developer who writes the actual code, there would be no need for code without stakeholders, and there would be no stakeholders without quality assurance of what they stand over.

我了解到，即使是由开发人员编写实际的代码，没有利益相关者也将不需要代码，而没有利益相关者的质量保证就不会有利益相关者。

结论 (Conclusion)

I hope you can learn something from these lessons. If you have some lessons you have learned, that you would like to share, I would love to hear them in the responses.

我希望您可以从这些课程中学到一些东西。 如果您想学到一些经验教训，希望与您分享，我很乐意在答复中听到他们的声音。

Thanks for reading!

谢谢阅读！

翻译自: https://www.freecodecamp.org/news/five-important-lessons-from-four-years-as-a-software-developer-9b367f256226/

经验教训 软件开发

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93801 人正在系统学习中 相关资源：Cableeye软件.rar-其它其他资源-CSDN文库