软件开发遵循标准_请遵循以下关键步骤来启动成功的软件开发项目

软件开发遵循标准

by Andrei Danciu

通过安德烈·丹丘(Andrei Danciu)

请遵循以下关键步骤来启动成功的软件开发项目 (Follow these key steps to start a successful software development project)

More often than not, the beginning of a project catches you unprepared. You might be on the project team from day one, but the schedule is tight and there’s not enough time for preparation. Even worse, you might overlook some steps, and that might come back to haunt you later.

通常，项目的开始会使您措手不及。 从第一天起，您可能就在项目团队中，但是时间表很紧，没有足够的准备时间。 更糟糕的是，您可能忽略了一些步骤，以后可能会再次困扰您。

The project kicks off, but after a few months you end up in a dark spot. Those annoying things that got you frustrated during your previous assignments are back.

该项目开始了，但是几个月之后，您最终陷入了一片空白。 在以前的工作中让您感到沮丧的那些烦人的事情又回来了。

If that sounds all too familiar, this article is for you. Follow these guidelines when starting a project and set yourself up for success.

如果听起来太熟悉了，那么这篇文章适合您。 启动项目时请遵循以下准则，并为成功做好准备。

建立清晰的沟通路径 (Establish clear communication paths)

Starting from day one, make sure that the roles are well-defined and everyone knows who handles what. People will request access to external systems, ask for clarifications, or signal emergencies. Whatever the scenario, make sure that the key contact persons are easily identified. Keep this information in a well-known location and make it accessible to everyone.

从第一天开始，请确保角色定义明确，并且每个人都知道谁来处理。 人们将要求访问外部系统，进行澄清或发出紧急信号。 无论哪种情况，请确保容易识别关键联系人。 将此信息保存在一个众所周知的位置，并使每个人都可以访问。

定义最佳做法和惯例 (Define best practices and conventions)

When the project kicks-off, don’t start coding right away. If you do that, more often than not your codebase will become a tangled mess that nobody wants to touch or maintain.

项目启动时，请勿立即开始编码。 如果这样做的话，您的代码库经常会变成混乱的混乱，没人想触摸或维护。

Take some time to assess your past experiences and identify what went well and what didn’t. It will help you define how you want things to happen for this new initiative. Involve the entire team in the exercise and make sure that you listen to what they’re saying.

花一些时间来评估您过去的经验，确定哪些方面做得好，哪些方面做不到。 它将帮助您定义此新计划要如何发生。 让整个团队参与练习，并确保您听取他们的意见。

The end result should be a list of conventions and best practices validated by the entire team. Follow these conventions and you’ll develop a much more well-organized and coherent solution.

最终结果应该是整个团队认可的约定和最佳实践的列表。 遵循这些约定，您将开发出更加井井有条的解决方案。

创建有意义的完成定义 (Create a meaningful Definition of Done)

How many times did you find out just before the demo that you can’t showcase a feature because something is missing? I know, too often.

在演示之前，您发现多少次因为缺少某些内容而无法展示功能？ 我经常知道

Developers tend to consider that a feature is done once it works on their local machine. However, a complete software development cycle involves much more than that.

开发人员倾向于认为某个功能在其本地计算机上工作后就可以完成。 但是，完整的软件开发周期所涉及的范围远远不止于此。

The feature might only work on your local machine, so you have to test it on at least another environment. Then, you should ask your peers to review your work. This ensures that the acceptance criteria and quality standards are being met.

该功能可能仅在您的本地计算机上起作用，因此您必须至少在另一个环境上对其进行测试。 然后，您应该要求您的同伴审查您的工作。 这样可以确保符合验收标准和质量标准。

The next step is to add the deployment steps, so that you can release the feature to the demo environment. You should put these steps together in the Definition of Done, along with any other relevant step.

下一步是添加部署步骤，以便您可以将功能发布到演示环境。 您应该将这些步骤以及所有其他相关步骤放到“完成的定义”中。

After that, make sure that your team uses the Definition of Done as a checklist before they complete a task. This will give you a lot more confidence that a resolved ticket is what you expect it to be.

之后，请确保您的团队在完成任务之前将“完成的定义”用作检查清单。 这将使您更加放心，已解决的票证将是您期望的。

选择合适的持续集成系统 (Choose an appropriate continuous integration system)

Continuous integration is crucial for every project. You want to make sure that you can release the new developments with minimal effort. Luckily, there is a wide range of options available on the market, Jenkins and TeamCity being two of them. There are a couple of very important factors to take into account when making this choice, though.

持续集成对于每个项目都至关重要。 您想确保可以毫不费力地发布新的开发成果。 幸运的是，市场上有多种选择， Jenkins和TeamCity是其中的两个。 但是，进行此选择时需要考虑几个非常重要的因素。

One of them is the preference of the team, and the other one is the price of the tool. It’s always wiser to use a continuous integration tool that your team has used before. That means that everyone is familiar with the tool and you won’t need to put in extra effort to learn a new system.

其中之一是团队的偏好，另一个是工具的价格。 使用团队之前使用的持续集成工具总是比较明智​​的。 这意味着每个人都熟悉该工具，而您无需花费额外的精力来学习新系统。

Don’t overlook the pricing factor, though. If your tool of choice is a pricey one, the project sponsors might not be willing to pay for it. We all know that this happens, but it’s not the end of the world.

不过，请不要忽略定价因素。 如果您选择的工具价格昂贵，则项目发起人可能不愿意为此付费。 我们都知道这种情况会发生，但这不是世界末日。

There are plenty of powerful continuous integration tools that are free. Take the time to test them and choose the most appropriate one for you.

有许多免费的强大的持续集成工具。 花一些时间测试它们，然后为您选择最合适的一种。

选择您的工具和应用程序 (Choose your tools and applications)

One thing that you want to avoid is using too many different tools for achieving the same purpose. Let’s imagine that your team has to develop a REST API.

您要避免的一件事是使用太多不同的工具来实现相同的目的。 假设您的团队必须开发REST API。

One of your less experienced team members, John, needs some help to test an endpoint for user creation. He asks Alex for assistance, who is eager to help, until she realizes that John is using SOAP UI to test his endpoints.

您经验不足的团队成员之一John，需要一些帮助来测试用于创建用户的端点。 他向渴望寻求帮助的Alex寻求帮助，直到她意识到John正在使用SOAP UI测试其端点。

Alex, a big fan of Postman, spends a few minutes trying to understand how to use the tool, but without too much success. She gives up after a few tries, so they decide to reach out to George, the most experienced guy on the team.

Alex是Postman的忠实拥护者，花了几分钟时间试图了解如何使用该工具，但并没有取得太大的成功。 经过几次尝试，她放弃了，因此他们决定联系小组中最有经验的人乔治。

However, George is an old-school programmer. He likes to do everything from the command line, so he asks John to rewrite his API calls to test them with cURL. It’s not an ideal situation for anyone.

但是，乔治是一名老派程序员。 他喜欢从命令行执行所有操作，因此他要求John重写他的API调用以使用cURL对其进行测试。 对于任何人来说，这都不是理想的情况。

We know that developers love to have the freedom to choose their own tools, but it’s not always optimal to work that way. In the long run, the team will benefit more from using the same toolset. Try to avoid this kind of situation by choosing specific tools for each purpose.

我们知道开发人员喜欢自由选择自己的工具，但是以这种方式工作并非总是最佳的。 从长远来看，使用相同的工具集将使团队受益更多。 通过为每种目的选择特定的工具来尝试避免这种情况。

Don’t be too rigid, listen to the preferences of your team, but make a clear choice. Also, make sure to explain to everyone why this is important and get the buy-in from your peers. After all, you don’t want to be a control freak.

不要太死板，听取团队的偏好，但要做出明确的选择。 另外，请务必向每个人解释为什么这很重要，并从同行那里获得支持。 毕竟，您不想成为控制狂。

明智地使用版本控制系统 (Use version control systems wisely)

Version control systems are a must for every software project. You cannot develop a software solution collaboratively without using one. However, it’s not enough to select a version control system and communicate the choice to your team.

版本控制系统对于每个软件项目都是必须的。 如果不使用软件解决方案，则无法协作开发软件解决方案。 但是，仅选择版本控制系统并将选择结果传达给团队是不够的。

You have to invest some time to define the way in which you want the system to be used for your new project. A good starting point is to compare the existing workflows and to decide what is the best one for your use case.

您必须花费一些时间来定义希望用于新项目的系统的方式。 一个很好的起点是比较现有的工作流程，并确定最适合您的用例的工作流程。

Next, you should validate the workflow with your team. If the feedback is positive, chances are that the version control system will be used as intended.

接下来，您应该与团队一起验证工作流程。 如果反馈是肯定的，则很有可能会按预期使用版本控制系统。

避免拥有多个文档管理系统 (Avoid having multiple document management systems)

One of the most frustrating things is when you need to find a piece of information and you don’t know where to look for it. This usually happens because there are too many places where it could be. It shouldn’t be that complicated!

最令人沮丧的事情之一是，当您需要查找一条信息而又不知道在哪里寻找信息时。 通常会发生这种情况，因为可能有太多地方。 它不应该那么复杂！

When your DevOps guy wants to find the IP of the QA server, he should have to look into a single place. To make this happen, you should choose one good document management system and stick to it.

当您的DevOps家伙想找到QA服务器的IP时，他应该不得不寻找一个地方。 为此，您应该选择一个好的文档管理系统并坚持下去。

Keep it organized and confront anyone who attempts to store information outside the system. Everyone will see the benefits in the long run, even the people that get shouted at.

保持组织井井有条，与任何试图在系统外部存储信息的人面对面。 从长远来看，每个人都会看到好处，即使是被大声疾呼的人。

定义解决方案所需的环境 (Define the environments required for your solution)

We all know that developers, testers, and business should not use the same environment. But this aspect is one usually overlooked during the initial phase of a project.

我们都知道开发人员，测试人员和企业不应使用相同的环境。 但是这一方面在项目的初始阶段通常被忽略。

You should start considering what environments are necessary for your projects early on. Getting approval and setting them up might take a while, so it’s better to start as soon as possible.

您应该尽早开始考虑项目所需要的环境。 获得批准并进行设置可能需要一段时间，因此最好尽快开始。

As a guideline, you should have at least four environments: development, User acceptance testing (UAT), staging, and production.

作为准则，您应该至少具有四个环境：开发，用户接受测试(UAT)，暂存和生产。

开发环境 (Development Environment)

The development environment will be the sandbox of the development team. That’s why it won’t be stable at all times, and you can expect data inconsistencies.

开发环境将成为开发团队的沙箱。 这就是为什么它不会一直稳定的原因，并且您可能会期望数据不一致。

用户验收测试环境 (User Acceptance Testing Environment)

The UAT is intended for user acceptance, so this is where the business people will do their testing.

UAT旨在供用户接受，因此业务人员将在此处进行测试。

登台和生产环境 (Staging and Production Environments)

Finally, the staging and production come hand in hand and they should mirror each other. This will ensure that the operations run on staging will have the same results on production.

最后，演出和制作是相辅相成的，它们应该相互反映。 这将确保按阶段运行的操作在生产上具有相同的结果。

But each project is different. You might need more environments than the ones above, or you won’t be able to have them all due to the high costs.

但是每个项目都是不同的。 您可能需要比上述环境更多的环境，否则由于成本高昂，您将无法拥有全部环境。

Whatever the case, make sure you consider the system landscape upfront and define what you need so that you can deliver the project.

无论如何，请确保先考虑系统环境并定义所需的内容，以便交付项目。

准备代码库和项目结构 (Prepare the codebase and project structure)

A well-organized codebase will go a long way. Start taking a few proactive steps early on, so that your project won’t soon turn into a big ball of mud.

组织良好的代码库将大有帮助。 尽早开始采取一些积极主动的步骤，以使您的项目不会很快变成一个泥泞的球。

You should define the main modules of the project, codebase structure, file naming conventions, packaging rules, and so on.

您应该定义项目的主要模块，代码库结构，文件命名约定，打包规则等。

Make it as intuitive as possible, so that is easy for everyone to find the things they are looking for. Also, look back to the lesson learned from previous projects and make sure you don’t repeat the same mistakes.

使它尽可能直观，这样每个人都可以轻松找到他们想要的东西。 另外，请回顾从以前的项目中学到的教训，并确保您不会重复同样的错误。

创建用于本地项目设置的文档 (Create a document for local project setup)

Even if you start with a very small team, chances are that you’re not going to be the only ones on the projects. When new people are about to join, you want to make their life as easy and possible and help them get up to speed in no time. This has to start with the local project setup.

即使您从一个很小的团队开始，也很可能您不会成为项目中唯一的人。 当新人们要加入时，您想让他们的生活变得轻松和可能，并帮助他们立即上手。 这必须从本地项目设置开始。

I’ve seen too many cases where the new guy has to spend an entire week to get the project running on his machine. This usually happens when the setup documentation was poorly written, incomplete, or missing altogether.

我见过太多的情况，新人要花整整一个星期才能使项目在他的机器上运行。 通常在安装文档写得不好，不完整或完全丢失的情况下发生。

To avoid this, start with a document that defines all the steps required for the project setup. Then, make sure to test it on your own and refine it.

为避免这种情况，请从定义项目设置所需的所有步骤的文档开始。 然后，请确保自行测试并优化它。

Next, ask your peers to review the installation steps and incorporate their feedback. You’ll end up with a concise, easy-to-follow setup guide that will quickly get everyone started.

接下来，请您的同龄人查看安装步骤并吸收他们的反馈。 您将获得一个简洁，易于遵循的设置指南，该指南将使每个人快速入门。

结语 (Wrapping up)

One more thing, though. Don’t treat this document as it is written in stone. Review it from time to time and don’t forget to include new required steps as the system evolves. Your team will thank you for that.

不过，还有一件事。 请勿将本文档写成石块，否则请对其进行处理。 时不时地对其进行检查，并且随着系统的发展，不要忘记包括新的必需步骤。 您的团队将为此感谢您。

These are a few key things that you can do to set up your next project for success. What would you add to this list? Please leave your thoughts below.

这些是您可以成功建立下一个项目的一些关键事项。 您将添加到该列表什么？ 请在下面留下您的想法。

翻译自: https://www.freecodecamp.org/news/follow-these-key-steps-to-start-a-successful-software-development-project-163c838e8fe1/

软件开发遵循标准