后端开发除了编码还要做什么

Whether you are learning to code, looking for a new job, or just want to improve your skills as a developer, you need to master the essential tools of team collaboration. These are as important as knowing how to code.

无论您是学习编码，寻找新工作，还是想提高开发人员的技能，您都需要掌握团队协作的基本工具。 这些和知道如何编码一样重要。

It is teamwork that makes or breaks software projects.

团队合作决定了软件项目的成败。

Your code will work eventually. If you want it to work “on time” and be of good quality, you and your team need to be organized.

您的代码最终将起作用。 如果您希望它“按时”工作并具有良好的质量，则您和您的团队需要组织起来。

• Everyone needs to know what they have to do and when每个人都需要知道他们必须做什么以及何时做
• People’s work should not overlap or clash人们的工作不应重叠或冲突
• Common rules need to be followed through by everyone每个人都必须遵循共同的规则

You can achieve this using the right processes and tools. You want your team to focus on coding 90% of the time (the remaining 10% are for coffee breaks and Windows Updates).

您可以使用正确的流程和工具来实现这一目标。 您希望您的团队将精力集中在90％的时间上(其余的10％用于休息时间和Windows Update)。

Here are three essential things you need to master.

这是您需要掌握的三项基本知识。

Git和Pull请求 (Git and Pull Requests)

Configuration management is the foundation of team collaboration in software. Many tools exist for it, but luckily one has become the absolute and ultimate reference: Git.

配置管理是软件中团队协作的基础。 有许多工具可以使用它，但是幸运的是，有一种工具已成为绝对和最终的参考： Git 。

Documentation on the key aspects is well described in the Git Book.

在Git书中很好地描述了关键方面的文档。

There are plenty of turnkey services to get started: GitHub is probably the most popular, but also BitBucket or GitLab.

有很多交钥匙服务可以开始使用： GitHub可能是最受欢迎的，但是BitBucket或GitLab也是如此。

A great graphical tool to work with is SourceTree. I recommend you master the command line before reaching for UI tools, though.

SourceTree是一个很好的图形工具。 不过，我建议您先掌握命令行，然后再使用UI工具。

Below are the questions you should know how to answer:

以下是您应该知道如何回答的问题：

• How do I merge or rebase my branch, and what is the difference?如何合并或重新设置分支基础，有什么区别？
• How do I resolve conflicts? For example, mine versus theirs versus manual merge我该如何解决冲突？ 例如，我的与他们的与手动合并

• What is a feature branch?

  什么是功能分支 ？

• What is a pull request?

  什么是拉取请求 ？

• What are the different collaboration workflows in Git?

  Git中有哪些不同的协作工作流程 ？

That’s it, and this is pretty straightforward. After reading the theory and with some practice, you will become a Git master in a jiffy.

就是这样，这很简单。 阅读理论知识并进行一些实践后，您将很快成为Git大师。

敏捷板 (The Agile board)

The first thing a team needs to do when starting a project or a larger task is to split the job. Over the last 10 years, the “Agile” methodology replaced the traditional waterfall planning. The Agile manifesto is here.

团队在开始项目或完成较大任务时需要做的第一件事就是拆分工作。 在过去的十年中，“敏捷”方法取代了传统的瀑布规划。 敏捷宣言在这里 。

Practically speaking it says “let’s not plan too much ahead, because inputs and assumptions we have today about the project will change”. This is almost always true, and nowadays there is hardly any team under the sun that is not (sometimes self-proclaimed) “Agile”.

实际上，它说“我们不要为未来做太多计划，因为我们今天对项目的投入和假设将会改变”。 这几乎总是正确的，如今在阳光下几乎没有一支团队没有(有时自称为)“敏捷”。

Here are the practical things you need to know:

这是您需要了解的实用知识：

• The most popular Agile way of working is Scrum. Divide your project into “sprints” of two weeks and put “tasks” in the content of the sprint. All the rest is for the future and is called the “backlog”. This is useful to track progress, adjust planning going forward, and improve team velocity over time.

  最受欢迎的敏捷工作方式是Scrum 。 将您的项目分为两个星期的“冲刺”，并将“任务”放入冲刺的内容中。 其余的一切都是为了将​​来，被称为“ 积压 ”。 这对于跟踪进度，调整未来计划以及随时间推移提高团队速度很有用。

• Another Agile approach is Kanban. The idea is to limit the number of tasks that are “in progress”. This way, you are sure to close one item fully before moving to the next. There are no sprints or time frames like in Scrum. You just go through tasks one after the other until you’re done.

  另一种敏捷方法是看板 。 这个想法是为了限制“进行中”的任务数量。 这样，您一定要先完全关闭一个项目，然后再移到下一个项目。 没有像Scrum中那样的冲刺或时间表。 您只是一个接一个地完成任务，直到完成。

In Agile, a software project will be split into tens or hundreds of tasks. You need a tool to manage them. The reference tool is JIRA.

在敏捷中，一个软件项目将被分成数十个或数百个任务。 您需要一个工具来管理它们。 参考工具是JIRA 。

Other tools exist of course, but you will probably have to work with JIRA at some point. So if you are new to these all the tools, just go for JIRA. There is a free 7 day trial. It is more than enough to get an overview of how things work. Again, this is fairly straightforward, and very well-documented.

其他工具存在 ，当然，但你可能会在某个时候与JIRA工作。 因此，如果您不熟悉这些所有工具，请使用JIRA。 有7天的免费试用期 。 概要了解工作原理是绰绰有余的。 再次，这是相当简单的，并且有据可查。

测试和持续集成 (Testing and Continuous Integration)

Git and agile tools allow teams to go fast. With speed inevitably come errors and bugs. Consider a team of five developers working on rather independent pieces of code. Each of them will make a pull request to the repository. Two problems can arise:

Git和敏捷工具使团队可以快速前进。 随着速度的发展，不可避免地会出现错误和错误。 考虑由五个开发人员组成的团队，他们从事相当独立的代码。 他们每个人都会向存储库发出请求请求。 可能会出现两个问题：

• Once the code of the “first developer” gets to the Git repository, the code of the others is no longer valid or working because some things have changed. This is not a mistake from “the first developer”, it is just life and it will happen.一旦“第一个开发人员”的代码进入Git存储库，其他代码便不再有效或无法正常工作，因为某些事情已经改变。 这不是来自“第一个开发人员”的错误，它只是生命，并且会发生。
• Once all the developers pushed their code to the Git repository, chances that everything work as expected out of the box are rather low. Again, this is not a reflection of poor teamwork. It will just happen.一旦所有开发人员将他们的代码推送到Git存储库，开箱即用的一切工作的可能性就很小。 同样，这并不表示团队合作不佳。 它只会发生。

Therefore, you need to test your software. Even after each developer has pushed their code? It would be great, but a waste of time.

因此，您需要测试您的软件。 即使每个开发人员都推送了代码之后？ 很好，但是浪费时间。

When other developers push their code, we’ll need to repeat this task. Should you test once everyone has pushed their code? Also great, but you’ll find bugs late in the process, which can delay the whole project. So how can you solve this?

当其他开发人员推送其代码时，我们将需要重复此任务。 一旦所有人都推送了代码，您是否应该进行测试？ 也很棒，但是您会在过程的后期发现错误，这可能会延迟整个项目。 那么如何解决呢？

Automated tests and Continuous Integration are there to the rescue.

自动化测试和持续集成可助您一臂之力。

Automated testing is a topic one could write many books about. Each language and framework has its own set of tools. Listing them all would not make sense here. Just keep in mind that testing is time consuming and not always planned for.

自动化测试是一个主题，人们可能会写很多书。 每种语言和框架都有自己的一套工具。 在这里列出它们都没有意义。 请记住，测试是耗时的，并非总是计划的。

Regardless, you should know how to write unit tests for your code and be proactive about writing them. If you don’t have time to actually do it, you should at least be aware that it’s wrong.

无论如何，您都应该知道如何为您的代码编写单元测试，并积极主动地编写它们。 如果您没有时间实际执行此操作，则至少应意识到这是错误的。

Continuous Integration is a process in which every push to your repository triggers a build and runs your tests automatically. A red flag is raised as soon as a faulty commit goes in. Pull requests should also be tested automatically before merging to avoid bugs that impact the whole team.

持续集成是一个过程，在此过程中，每次推送到存储库都会触发构建并自动运行测试。 一旦有错误的提交进入，就会发出一个红旗。在合并之前还应该自动测试Pull请求，以避免影响整个团队的错误。

Continuous Delivery is the extension of Continuous Integration. If the tests pass properly, the tested version is pushed to the production environment automatically.

持续交付是持续集成的扩展。 如果测试正确通过，则测试版本将自动推送到生产环境。

As an example: at Quora, they track the time between a push to the repository and deployment of that code to production servers. The last benchmark I read about was 15 minutes … for around 100 developers. This is the most powerful setup a team could hope for.

例如，在Quora上 ，他们跟踪从推送到存储库到将代码部署到生产服务器之间的时间。 我读到的最后一个基准测试是15分钟，大约是100个开发人员。 这是团队所希望的最强大的设置。

Popular continuous integration servers are Jenkins, Travis, CircleCI, and a few more. You do not need to know how to set the server up and everything, but you should know such tools exist, and a red alert should trigger in your head if your team do not use any.

流行的持续集成服务器是Jenkins ， Travis ， CircleCI等。 您不需要知道如何设置服务器以及所有内容，但是您应该知道此类工具的存在，如果您的团队不使用任何工具，就会在您的头脑中触发红色警报。

结论 (Conclusion)

The core of a developer’s job is coding. Once you move from solo/hobbyist to member of a performing team, proper use of the key collaboration tools is as important as writing clean code. Hopefully this article gave you an overview of what these tools are and how to dig further to be the best at what you do!

开发人员工作的核心是编码。 从独奏/爱好者转到表演团队成员后，正确使用关键协作工具与编写清晰的代码一样重要。 希望本文概述了这些工具是什么，以及如何进一步挖掘以使其在您的工作中发挥最大作用！

Thanks for reading! If you find the article useful please hit the clap button below. It would mean a lot to me and it helps other people see the story!

谢谢阅读！ 如果您发现该文章有用，请点击下面的拍手按钮。 这对我来说意义重大，而且可以帮助其他人看到这个故事！

翻译自: https://www.freecodecamp.org/news/3-essential-skills-every-developer-should-master-besides-coding-80e40e084241/

后端开发除了编码还要做什么