开发工业软件需要什么人员_作为软件开发人员的第一周会发生什么-CSDN博客

开发工业软件需要什么人员

by Harriet Ryder

哈里特·莱德(Harriet Ryder)

作为软件开发人员的第一周会发生什么 (What to expect in your first week as a Software Developer)

You know you enjoy coding, but what’s it like doing it for a job? What might you expect in your first week?

您知道自己喜欢编码，但是从事这项工作感觉如何？您第一周会有什么期望？

I couldn’t imagine my first week in a new job. Do you start coding right away? What if they use a language/framework you haven’t learned? How do you get up to speed with the codebase, and know what the priorities are? Is it easy to slot into the team? Do you just… open up your editor and start coding? What if you get something horribly wrong and break everything?

我无法想象我在新工作的第一周。您立即开始编码吗？如果他们使用您没有学过的语言/框架怎么办？您如何快速掌握代码库，并知道优先级是什么？加入团队容易吗？您是否只是…打开编辑器并开始编码？如果您遇到严重错误并破坏了所有内容该怎么办？

I worked for 2 years at a coding bootcamp, and I heard similar questions from lots of students. They knew they liked coding, and loved what they were doing at the bootcamp on a daily basis - but they wanted to know what it feels like to go into a real job.

我在一个编码训练营工作了两年，并且听到很多学生都提出了类似的问题。他们知道自己喜欢编码，并且每天都喜欢自己在训练营中所做的事情-但他们想知道从事一份真正的工作的感觉。

In this post, I’ll use examples of what I did during the first few days in my most recent role to try and give you an idea of what you might expect.

在本文中，我将以最近几天担任我最近一职时的工作示例为例，以使您对可能的期望有所了解。

背景 (Background)

I am working as a full stack developer in a smallish company. There are four developers in the engineering team (including me) and a CTO. We also work closely with a Product Owner, who is one of the founders. I went in with a couple of years of coding experience.

我在一家小公司担任全职开发人员。工程团队(包括我)和CTO中有四个开发人员。我们还与创始人之一的产品负责人紧密合作。我进入了几年的编码经验。

All services are on AWS and we use NodeJS and Ruby.

所有服务都在AWS上，并且我们使用NodeJS和Ruby。

第一天：主要是设置 (Day 1: Mostly Setup)

I arrived at the office at 9am. A shiny new MacBook Pro was waiting for me on my desk, complete with adaptors and two screens. The dev team took me out for breakfast at a nearby cafe, and when we got back I sat down and started getting my machine set up.

我是早上9点到达办公室的。闪亮的新MacBook Pro在我的桌上等着我，配备适配器和两个屏幕。开发团队带我去附近一家咖啡馆吃早餐，当我们回来时，我坐下来开始安装机器。

Since I’ve set up countless dev environments before while working at a coding bootcamp, this was pretty straightforward and didn’t take me long. However, I had only set up a Ruby/Rails environment on my own laptop once, so that part took me a little longer.

由于在进行编码训练营之前，我已经建立了无数的开发环境，因此这非常简单，并且用了很长时间。但是，我只在自己的笔记本电脑上设置了一个Ruby / Rails环境，所以这花了我一点时间。

I was provided with an A4 sheet listing the requirements, version numbers, and so on which I made sure to follow carefully. I was also given access to various sites like BitBucket, a password manager, AWS and Gitlab and set up my SSH keys on my new machine.

为我提供了一张A4表格，其中列出了要求，版本号等，因此请务必仔细阅读。我还获得了访问各个站点的权限，例如BitBucket，密码管理器，AWS和Gitlab，并在新计算机上设置了SSH密钥。

Before lunch, I went for a chat with the CTO and we talked in detail about the product, the architecture, and the goals and priorities the dev team have for the foreseeable future.

午餐前，我与CTO聊天，我们详细讨论了产品，体系结构以及开发团队在可预见的未来中的目标和优先事项。

After lunch, I cloned down some of the services that make up the application and began to familiarise myself with the codebase. Luckily for me, I joined the team at a time when there were some new, fresh parts of the service under development which means I didn’t have too much code to get up to speed with.

午餐后，我克隆了组成该应用程序的一些服务，并开始熟悉代码库。对我来说幸运的是，我在开发过程中有一些新的，新鲜的部分加入了团队，这意味着我没有太多的代码需要跟上。

For the last couple of hours of the day, I sat with one of the senior developers while he implemented a feature. We used it as an opportunity for him to guide me through that part of the app, explaining why things had been done in specific ways, the parts that had caused problems, and the aspects that might end up changing in the future.

在一天的最后几个小时里，我与一位高级开发人员坐在一起，当他实施一项功能时。我们利用它为他提供了指导我浏览应用程序那部分的机会，解释了为什么以特定方式完成事情，导致问题的部分以及将来可能会改变的方面。

第2天：测试 (Day 2: Testing)

I was given the task of testing a couple of functions in one of the repos for the app. Giving new hires tests to write is a great way of introducing them to a codebase and familiarising them with some of the logic of the application.

我承担了在该应用程序的一个回购中测试几个功能的任务。给新员工编写测试是将它们引入代码库并使他们熟悉应用程序某些逻辑的一种好方法。

I spent a fair bit of time just reading the code, figuring out how it all worked together, and seeing if I could follow the flow of the logic. I was interested in the conventions the team had chosen, the way the code had been split up, and the stylistic choices. Writing the tests was not hard, but I’m always really cautious making my first mark on a codebase I haven’t worked on before!

我花了相当多的时间阅读代码，弄清楚它们是如何协同工作的，并查看我是否可以遵循逻辑流程。我对团队选择的约定，代码的拆分方式以及样式选择感兴趣。编写测试并不难，但是我总是非常谨慎地在从未使用过的代码库上取得第一分！

I didn’t want my work to stick out, so I attempted to observe and absorb the code style that was currently being used. To some extent, having good practices like linting helps a lot, but there’s also just general architectural and stylistic choices that linting can’t help you with.

我不希望我的工作继续下去，所以我尝试观察并吸收当前使用的代码样式。在某种程度上，拥有诸如棉绒之类的良好实践会有所帮助，但是棉绒无法满足您的一般建筑和风格选择。

One slight challenge I had was getting used to the Git workflow that the team used. Every team has their own way of doing things: some teams merge, some teams rebase, some teams squash commits and others don’t, some follow popular workflows like this one, and others just force push into master willy nilly. Plus there’s the conventions of the commit message and description to get right, the reviewing process, and so on.

我遇到的一个小挑战是适应团队使用的Git工作流程。每个团队都有自己的处理方式：一些团队合并，一些团队调整基础，一些团队压榨提交而另一些则没有，一些遵循这种流行的工作流程，而其他一些则强行推入主人Willy Nilly。加上提交消息的约定和正确的描述，审阅过程，等等。

All in all, there’s a lot of non-explicit “this is how we do things” stuff to pick up. After going through the process a couple of times, correcting my mistakes and asking questions, it’s now second nature.

总而言之，有很多不明确的“这就是我们做事的方式”的东西。经过几次该过程，纠正了我的错误并提出了问题之后，这已成为第二天性。

All the time I was writing notes in a notebook and keeping code snippets in an application called Bear. There was so much to take in — how to do things, the preferred procedures for the team, things I hadn’t done before, and new languages and frameworks to learn.

我一直在笔记本上书写笔记，并在名为Bear的应用程序中保存代码段。有很多东西需要去做—如何做事情，团队喜欢的程序，我以前没有做过的事情以及要学习的新语言和框架。

I needed to be really active in noting down what I was learning. I made it a point at the end or beginning of every day to review my notes, add extra explanations to things I’d written in a hurry, and research stuff I didn’t fully understand. All of this also took up some time.

我需要非常主动地记下我所学的内容。我在每天结束时或开始时都着重于检查笔记，对我匆忙编写的内容添加额外的解释以及研究我不完全了解的内容。所有这些也花费了一些时间。

第3天：强化AWS (Day 3: Spiking AWS)

As part of the release we had in progress, we needed to decide how to deploy a service we were building. We were using AWS, but there was a choice between using a EC2 instance which would be the simplest choice, as it’s just a server in the cloud running your application, or something a bit fancier like Elastic Container Service. The benefit of ECS is that it would manage the scaling of multiple EC2 instances and therefore be a good option for the future. But it wasn’t completely essential for the time being.

作为我们正在进行的发行的一部分，我们需要确定如何部署我们正在构建的服务。我们使用的是AWS，但是可以选择使用EC2实例，这是最简单的选择，因为它只是运行应用程序的云中的服务器，或者像Elastic Container Service这样的更奇特的东西。 ECS的好处是它将管理多个EC2实例的扩展，因此是将来的不错选择。但这暂时还不是完全必要的。

Given this, I was given (volunteered for) the task of spiking out how easy it would be to deploy our service on ECS. Spiking just means trying something out to explore feasibility. If it was going to be hard, it wasn’t worth it, since it was a future optimisation we didn’t desperately need it right now.

鉴于此，我被赋予(自愿参加)一项任务，以突出在ECS上部署我们的服务有多么容易。掺入只是意味着尝试一些东西来探索可行性。如果这很难，那是不值得的，因为这是一个未来的优化，我们现在并不急需它。

This involved a lot of learning for me, as I hadn’t used Amazon’s ECS before, plus the app was a Rails app and I was much less familiar with the whole Ruby/Rails ecosystem. I had spent maybe a total of 30 hours learning Ruby before joining the company, since I knew it was part of their stack, but I’d barely touched Rails. Plus, the task involved a bit of work with Docker, which was also new to me.

这对我来说涉及很多学习，因为我以前从未使用过Amazon的ECS，而且该应用程序是Rails应用程序，而我对整个Ruby / Rails生态系统的了解却少得多。加入公司之前，我大概花了30个小时学习Ruby，因为我知道Ruby是他们的一部分，但是我几乎没有接触过Rails。另外，该任务涉及到Docker的一些工作，这对我来说也是新的。

My tech lead got me started off with what was basically a 1-hour intro to Docker which was hugely useful. From there, I spent most of the day creating a new Rails app and following various articles, docs, and examples to see if I could get the thing running on ECS. I almost got there, but getting the database integration to work proved a stumbling block. There was just so much new stuff.

我的技术主管使我从Docker的1小时入门开始，这非常有用。从那以后，我花了整整一天的时间创建一个新的Rails应用程序，并关注各种文章，文档和示例，以查看是否可以在ECS上运行它。我几乎到了那里，但是使数据库集成正常工作是一个绊脚石。有太多新东西了。

I’m sure someone more familiar with either ECS or Rails wouldn’t have had so much trouble. I couldn’t come away saying that the process was objectively hard. It was hard for me, but that didn’t mean it was hard for everyone.

我敢肯定，更熟悉ECS或Rails的人不会遇到太多麻烦。我不能说这个过程客观上很困难。这对我来说很难，但这并不意味着每个人都很难。

Not a hugely productive day in terms of usable code or output, but I felt like I learned a lot and from that perspective and it was great.

就可用的代码或输出而言，这不是一个高产的日子，但是我觉得我学到了很多东西，并且从这个角度来看，这很棒。

第四天：配对和指导 (Day 4: Pairing and mentoring)

I arrived at the office at 8am, and while I was waiting for others to arrive I followed part of a Docker course I’d been watching on Pluralsight. I was still keen to finish off the spike from yesterday, but recognised that I needed more of a grounding in at least one of the new technologies that I was working with.

我是在早上8点到达办公室的，当时我在等待其他人的到来时，我参加了我在Pluralsight上观看过的Docker课程的一部分。我仍然很想结束昨天的涨幅，但是意识到我需要至少在我正在使用的一种新技术上有更多的基础。

I spent about an hour on the course, before more people arrived at the office and we set about deciding who’d do what. Another new developer, who had started a little before me, had just got back from holiday. We decided we would pair together on a task. We were building a new feature in the Rails app. This was quite a simple task, but Rails was new for both of us so it was great to work through it together. When we needed something explained, we would simply ask one of the other devs, either in person or on Slack. We had some great discussions this way and I began getting the hang of how Rails works.

我花了大约一个小时的时间，然后才有更多的人到达办公室，我们开始决定谁去做。另一位刚刚在我之前开始的新开发人员刚刚从假期回来。我们决定在任务上结成对。我们正在Rails应用程序中构建一个新功能。这是一个非常简单的任务，但是Rails对我们俩都是新手，因此一起完成这项工作真是太好了。当我们需要一些解释时，我们可以亲自或通过Slack询问其他开发人员之一。这样我们进行了一些精彩的讨论，我开始了解Rails的工作原理。

In the afternoon, I had a mentoring session with the tech lead which was generous since I’d already got a private Docker class just the day before! Mentoring is an opportunity to take questions, run through problems together, learn something together, or just pick someone’s brain. The knowledge transfer is very beneficial.

下午，我与技术负责人进行了一次指导会议，这次会议非常慷慨，因为前一天我已经参加了私人Docker培训班！指导是一个机会，可以提出问题，一起解决问题，一起学习某些东西，或者只是开动脑子。知识转移是非常有益的。

I had lots of odd questions about database stuff and Rails, but I regret not having one single goal for that first session. I guess I just wasn’t sure what to expect. In subsequent sessions, I’ve asked my mentor to show me how to do something specific like configure an NGINX server or configure an EC2 instance to have access to a database — things which he would already know, but would take me much longer to figure out on my own.

关于数据库内容和Rails，我有很多奇怪的问题，但是我很遗憾第一届会议没有一个目标。我想我只是不确定会发生什么。在随后的课程中，我已经请我的导师向我展示如何做一些特定的事情，例如配置NGINX服务器或配置EC2实例以访问数据库，这是他早已知道的，但是要花更长的时间才能弄清楚我一个人出来

第5天：会议和合并 (Day 5: Meetings and merges)

Many software teams will use combinations of stand up meetings (often daily), regular retrospectives (about working practices or technical issues), and planning sessions to organise their workflow at a high level, in combination with some sort of tracking tool where the work in progress and work left to do can be visualised.

许多软件团队将结合使用站立会议(通常是每天一次)，定期回顾(关于工作实践或技术问题)和计划会议的组合，以结合更高级别的工作流程来跟踪其工作流程。进度和剩下要做的工作可以可视化。

Our team is no different, and we have the majority of our scheduled meetings on a Friday. Like many teams, the emphasis during our meetings is to reflect on how we’ve been working and what we’ve achieved, to collectively solve any problems or blocks, and to identify and plan upcoming work so we’ve always got something ahead of us ready to move on to.

我们的团队没有什么不同，我们大多数预定的会议在星期五举行。像许多团队一样，我们会议期间的重点是反思我们的工作方式和成就，共同解决任何问题或障碍，并确定和计划即将开展的工作，因此我们总是要有所作为我们准备继续前进。

We also go out to breakfast to bond, which is awesome!

我们还出去吃早餐，这很赞！

All in all, most of the morning was spent on these activities. I had little to contribute as I was still getting my head around all the terminology and the structure of the product, and I was always about a sentence behind, trying to catch up with what had just been said. I remember during that first week just feeling like my brain was melting as I tried to hold all the various components of the architecture together in my mind (it gets better as time progresses, so don’t worry!).

总而言之，早上大部分时间都花在了这些活动上。我几乎没有做出任何贡献，因为我仍然对所有术语和产品结构有所了解，而且我总是在后面一句话，试图追赶刚才所说的内容。我记得在第一周的时候，我试图将架构的所有各个组成部分集中在一起时感觉就像大脑在融化(随着时间的流逝，它会变得越来越好，所以不用担心！)。

In the afternoon, my pair and I were able to finish off what we’d been working on, solicit a code review, make amendments, and open a request to merge our work into the app. We didn’t deploy as it was a Friday afternoon but we did on the following Monday. ?

下午，我和我俩完成了我们一直在做的工作，征求了代码审查，进行了修改，并提出了将我们的工作合并到应用程序中的请求。我们没有部署，因为它是星期五的下午，但我们在下一个星期一进行了部署。？

Thanks for reading, I hope this article gave you some idea of what your first week as a developer might look like.

感谢您的阅读，我希望本文能使您了解作为开发人员的第一周的情况。

I’d love to hear your comments and experiences!

我希望听到您的评论和经验！