本文共 8553 字，大约阅读时间需要 28 分钟。
入职开发很少写代码
Imagine that only a decade ago system administrators deployed, configured, and maintained software systems manually. Doing so burned an endless amount of their precious lifetimes and energy.
想象一下，只有十年前，系统管理员才手动部署，配置和维护软件系统。 这样做消耗了他们无穷无尽的宝贵生命和精力。
Today, in the age of microservice architectures, systems have become even more complicated. Trying to maintain operations and deployments by hand isn’t optional anymore. These days we do “DevOps” or “Infrastructure as code”. We have learned that describing a software system in a declarative and formal way is mandatory to deploy applications automatically and continuously.
如今，在微服务架构时代，系统变得更加复杂。 尝试手动维护操作和部署不再是可选的。 这些天，我们做“ DevOps”或“基础设施即代码”。 我们已经了解到，以声明和正式的方式描述软件系统对于自动连续地部署应用程序是必不可少的。
While we have automated deployments of our applications, most of us don’t apply the same techniques to development environments, yet. Instead, on-boarding a new team member on any non-trivial project usually is a multiple hour (if not days) exercise.
虽然我们已经对应用程序进行了自动部署，但是我们大多数人还没有将相同的技术应用于开发环境。 取而代之的是，在任何不重要的项目中加入新的团队成员通常需要花费几个小时(如果不是几天的话)。
It often goes like that:
通常是这样的：
A new developer gets pointed to the readme
一个新的开发人员指向自述文件
Reads lengthy, mostly outdated setup procedure
读取冗长的，大多是过时的设置过程
Installs requirements on the developer machine,
在开发机器上安装要求，
Installs requirements on the developer machine, updates/downgrades versions, etc.
在开发人员机器上安装要求， 更新/降级版本等。
Tries to run the build … waits 20 minutes
尝试运行构建…等待20分钟
Build Fails. Try figure out what went wrong.
生成失败。 尝试找出问题所在。
Asks colleague. “Oh, yes. You also need to do X & Y”
问同事。 “哦，是的。 您还需要做X＆Y”
goto 3
转到3
After many iterations at some point, the build somehow works. You don’t know why, but that doesn’t matter now. Of course, you are not updating the document, as you are not sure and don’t know how you ended up with a working setup. Is that current state even reproducible? So if you update the readme, you better only add what you figured out. You don’t dare to remove parts that you didn’t understand or skipped because they didn’t work for you.
在某些时候经过多次迭代之后，构建便可以正常工作了。 您不知道为什么，但是现在不重要了。 当然，您不确定是否要更新文档，因为您不确定也不知道最终如何进行有效的设置。 该当前状态是否可以重现？ 因此，如果您更新自述文件，最好只添加您想出的内容。 您不敢删除不了解或跳过的部分，因为它们对您不起作用。
Too bad the setup only worked on first glance. During the following weeks, you will have to solve smaller issues here and there and add some tools that were not listed. Maybe debugging doesn’t work yet, or you don’t see the sources from upstream dependencies. Eventually, it smoothes out. Only when a colleague changes something in the requirements, it usually takes two days until the whole team has noticed and changes their environments accordingly.
太糟糕了，该设置仅在乍看之下起作用。 在接下来的几周中，您将不得不在这里和那里解决较小的问题，并添加一些未列出的工具。 也许调试还不起作用，或者您看不到上游依赖项的源。 最终，它变得平滑了。 仅当同事更改需求中的内容时，整个团队通常要花两天时间，并相应地更改他们的环境。
Unfortunately, the pain doesn’t stop here.
不幸的是，痛苦不止于此。
You probably know the famous phrase “It works on my machine”? The situation when a bug only appears on one machine and is hard to reproduce on others? That feeling when a bad thing happens in production, but you can’t reproduce it locally? Not very surprising, though, as long you are running the code on a different platform based on a different setup.
您可能知道著名的短语“它可以在我的机器上工作”吗？ 当错误仅出现在一台计算机上而很难在另一台计算机上重现时的情形？ 生产中发生坏事时的那种感觉，但是您无法在本地复制？ 但是，只要您在基于不同设置的不同平台上运行代码，就不会太令人惊讶。
Another pet peeve is when you need to fix something on a maintenance branch. Fixing the actual bug could have been so easy, as you know how to fix it. However, before you can call it done you need to be able to build and test that old beast. This is costing you an endless amount of time.
另一个烦恼是当您需要在维护分支上修复某些东西时。 正如您知道如何修复一样，修复实际的错误可能非常容易。 但是，在完成它之前，您需要能够构建和测试该古老的野兽。 这会花费您无尽的时间。
Tinkering with a six months old technology stack can be so annoying. You have to deal with all those old libraries and versions of them. However, you still have to make it work somehow.
修补使用六个月的技术栈可能会很烦人。 您必须处理所有这些旧库及其版本。 但是，您仍然必须以某种方式使其工作。
All this suffering can end if we applied the ‘infrastructure as code’ idea to our dev environments, too. Why not make dev environment setups automated, reliably reproducible, and versioned by writing them down in an executable format and checking them into the project’s source code repository?
如果我们也将“基础架构即代码”理念应用到我们的开发环境中，所有这些痛苦都可以消除。 为什么不通过以可执行的格式写下开发环境设置并将其检查到项目的源代码存储库中，从而使开发环境设置实现自动化，可靠地可复制和版本控制？
After all, dev environments are often even more complicated than the runtime application they are used for. You typically need to add all the development tools such as build tools, compilers, linters, and a decent editor / IDE on top of the runtime requirements.
毕竟，开发环境通常比它们所使用的运行时应用程序还要复杂。 通常，您需要在运行时需求之上添加所有开发工具，例如构建工具，编译器，lint和一个不错的编辑器/ IDE。
If you want to ensure that changes don’t break anything down the line, everybody needs to code, run, and test on the same environment the CI builds run on.
如果要确保所做的更改不会破坏一切，那么每个人都需要在运行CI的相同环境下进行编码，运行和测试。
So let’s please stop polluting our readme files and start writing setup instructions down formally, so they can be executed.
因此，让我们停止污染我们的自述文件，并开始正式写下安装说明，以便可以执行它们。
Docker files are a pretty neat way to describe a development environment. Imagine you want to add something like ‘asciidoctor’ to your project’s toolchain. You could just add the following line to your dev environment’s Dockerfile:
Docker文件是描述开发环境的一种非常简洁的方法。 想象一下，您想在项目的工具链中添加类似“ asciidoctor ”的内容。 您可以将以下行添加到开发环境的Dockerfile中：
RUN apt-get install -y asciidoctor
Once you push the change to the repository and the docker image gets updated (automatically), all team members have the new tool in their development environment. We need to get to coding with a single click.
将更改推送到存储库并且docker映像得到更新(自动)后，所有团队成员都在其开发环境中拥有新工具。 我们需要单击一下编码。
Disclaimer: I am affiliated with some of the tools mentioned below.
免责声明：我隶属于下面提到的一些工具。
The Docker approach gets a bit clumsy if your development tools have a UI such as a desktop IDE. You can package them in Docker, but you have to expose the IDE’s UI through X11. Another alternative is to go with a terminal editor like vim, but of course, that is not an option for most of us.
如果您的开发工具具有UI(例如桌面IDE)，则Docker方法会显得有些笨拙。 您可以将它们打包在Docker中，但是必须通过X11公开IDE的UI。 另一个选择是使用像vim这样的终端编辑器，但是对于我们大多数人来说，这当然不是一个选择。
Some desktop IDEs have tools that allow automating setups. Eclipse, for instance, has a tool called Oomph. Oomph allows you to declaratively describe an Eclipse IDE including plug-ins, configuration and even workspace setup. (i.e. git information).
某些桌面IDE具有允许自动设置的工具。 例如，Eclipse有一个名为Oomph的工具。 Oomph允许您以声明方式描述Eclipse IDE，包括插件，配置甚至工作区设置。 (即git信息)。
By far the best option is an IDE that runs in browsers, like the new DE. Theia is open-source under the Eclipse Foundation. It can be seen as VS Code that runs on browsers and desktops and is a bit more customizable.
到目前为止，最好的选择是在浏览器中运行的IDE，例如新的 DE。 Theia是Eclipse Foundation之下的开源。 可以将其视为在浏览器和台式机上运行的VS Code，它的可定制性更高。
For a simple Docker-based dev environment you could add Theia to your Docker image. It offers a full IDE including terminals to your workspace image.
对于基于Docker的简单开发环境，可以将Theia添加到Docker映像中。 它提供了完整的IDE，包括工作区映像的终端。
The next step would be to treat your development environment as some serverless function which you only spawn when needed and forget about when done. The online service does exactly that.
下一步将把您的开发环境视为一些无服务器功能，您仅在需要时才生成该功能，而在完成时却忘记了。 在线服务正是这样做的。
It integrates with code hosting platforms such as GitHub. It eliminates all the tedious transitions by automating them. You see code on some website and want to give it a spin in a real dev environment? Gitpod does everything it can to get you there with a single click. It lets you provide custom Docker files or Docker images and runs Theia IDE.
它与GitHub等代码托管平台集成。 它通过自动化消除了所有繁琐的转换。 您在某个网站上看到了代码，并想在实际的开发环境中试用一下吗？ 只需单击一下，Gitpod就会竭尽所能。 它可让您提供自定义Docker文件或Docker映像并运行Theia IDE。
Applying the lessons learned from DevOps to our development setup can save us so much precious time and energy. underlines this with some numbers:
将从DevOps中汲取的经验教训应用到我们的开发设置中，可以为我们节省很多宝贵的时间和精力。 通过以下数字强调了这一点：
Do we really need to welcome new colleagues or contributors with a painful on-boarding experience? Let’s skip the prose in the readme and write code to have our dev environment setup automated, reproducible, and versioned.
我们真的需要以痛苦的入职经验欢迎新同事或贡献者吗？ 让我们跳过自述文件中的散文，编写代码以自动，可复制和版本化我们的开发环境。
翻译自:
入职开发很少写代码
转载地址：http://lywzd.baihongyu.com/