软件工程与软件测试基础知识_这是我在软件工程工作九个月中学到的知识

软件工程与软件测试基础知识

I’ve been working for about nine months at Dexter as a software developer. I wrote a blog post about landing the job initially, as well as a technical post about a self positioning component I made in my first couple of months at the company. Getting a job was my initial goal, and keeping it and growing as a developer was the natural next step forward.

我作为软件开发人员在Dexter工作了大约9个月。 我写了一篇有关最初从事这项工作的博客文章，以及一篇有关我在公司头几个月中所做的自我定位组件的技术文章。 找工作是我的最初目标，而保持并成长为开发人员是自然而然的下一步。

My thoughts about my role have changed significantly since I started. I thought being a developer was about cranking out code as quickly as possible. It’s the furthest thing from reality. Banging out a lot of crappy code quickly isn’t a scalable way to build a business or a career in development. Luckily, I found an employer who felt the same way, and whose product is software.

自从我开始工作以来，我对自己角色的看法发生了很大变化。 我以为成为开发人员就是要尽快编写代码。 这是现实中最遥远的事情。 快速发布大量糟糕的代码不是建立企业或从事开发事业的可扩展方式。 幸运的是，我找到了一个也有同感的雇主，其产品是软件。

The goal is to write just the right amount of good code and communicate well. You’re not paid to code, you’re paid to think and figure out problems. The byproduct is crystallized thought and instruction for a machine to follow in the form of code. I’d rather solve a problem in one line of clear readable code than 10 lines of code that’s difficult to understand. I’d rather solve a problem in 5 lines of readable commented code than one line of highly complex, multi-nested code with multiple ternary operators. You get the idea.

目的是编写适量的优质代码并进行良好的沟通。 您无需支付代码，也无需考虑思考和找出问题。 副产品是机器的明确思想和说明，以代码的形式遵循。 我宁愿用一行清晰的可读代码解决一个问题，而不是用10行难以理解的代码解决问题。 我宁愿用5行可读的注释代码解决一个问题，而不是用多个三元运算符编写高度复杂的多嵌套代码。 你明白了。

提出很多问题，并记录答案 (Ask lots of questions, and document the answers)

My boss sent me this link which encapsulated a lot of the stress and anxiety I feel as a new engineer. It’s an understatement to say I’m very self-conscious about asking questions.

我的老板给我发送了这个链接，其中包含了我作为新工程师时感到的许多压力和焦虑。 轻描淡写地说我对提出问题非常自觉。

I use this checklist before asking others for help:

在向他人寻求帮助之前，我使用此清单：

• Is this a question that I’ve asked before, and if so, where did I document the answer?
  这是我之前问过的一个问题吗？如果是，我在哪里记录了答案？
• Is this something I could Google?
  这是我可以给Google带来的东西吗？
• Is this documented somewhere by someone else internally?
  这是内部其他人记录的吗？
• What’s going on here? What’s the root cause of the error or unexpected behavior that I’m experiencing?
  这里发生了什么？ 我遇到的错误或意外行为的根本原因是什么？
• Do I really understand the question I’m trying to answer? It’s okay to take some time and read over the problem again rather than giving a half-ass or rushed answer.
  我真的了解我要回答的问题吗？ 可以花一些时间重新阅读问题，而不是半途而废或匆忙回答。

After following these steps, I solve the problem on my own, find a documented solution, or ask a question with much better context and detail which makes it easier for someone else to help me. Even better, if I ask a good question and it can be answered over chat, my teammate doesn’t need to drop everything to help me.

按照这些步骤操作后，我可以自行解决问题，找到有案可稽的解决方案，或者以更好的上下文和详细信息提出问题，这使其他人更容易帮助我。 更好的是，如果我问一个很好的问题并且可以通过聊天回答，那么我的队友就不必为了帮助我而放弃一切。

If I’ve gone 90% of the way towards solving the problem and just need the last 10% of help, a senior developer is going to be happy to help knowing that I got as far as I could on my own. Looking for someone else to solve your problems isn’t a great way to build trust within your team.

如果我已经花了90％的时间来解决问题，而只需要最后10％的帮助，那么一位资深的开发人员将很乐意为您提供帮助，以帮助我了解自己的能力。 寻找别人来解决您的问题并不是在团队中建立信任的好方法。

Smart people like good questions — so ask them.

聪明的人喜欢好的问题-所以问他们。

避免犯同样的错误，一遍又一遍地问相同的问题 (Avoid making the same mistakes and asking the same questions over and over again)

This is easier said than done, and could be true for any job, not just programming. A lot of new concepts and information are being thrown your way, and making mistakes is inevitable. Be aware of that. Think before you ask. Google stuff. Look at the docs. They’re your friend. If you see a trend, try and identify it. Make an active effort to catch yourself asking the same type of question. Write it down, and make it a goal to fix it.

这说起来容易做起来难，并且对任何工作都适用，而不仅仅是编程。 大量新概念和新信息被扔向您的方向，犯错误是不可避免的。 注意这一点。 在问之前先三思。 Google的东西。 看一下文档。 他们是你的朋友。 如果看到趋势，请尝试识别。 做出积极的努力，让自己问同样的问题。 写下来，并将其作为修复它的目标。

Make sure that the next time you come across the same issue you know what to do. We all make mistakes, but being self-aware and making an effort to change is how everyone gets better.

确保下次遇到相同问题时，您知道该怎么办。 我们每个人都会犯错，但是要自我意识并努力改变，这就是每个人都会变得更好的方法。

始终回顾您的工作 (Review Your Work, Always)

No one likes going through a PR and telling you to remove your console.logs and debuggers or telling you to fix linting errors. I wouldn’t publish this post without reading it over a couple of times and having a friend take a look, too.

没有人喜欢通过PR告诉您删除console.logs和调试器，或告诉您修复掉毛错误。 我不会在不阅读几次并且也要有朋友看的情况下发布这篇文章。

Really look at your code and ask yourself these questions:

真正看一下您的代码并问自己以下问题：

• I wrote a complex piece of logic. Is there similar functionality in the application that maybe does this in a more readable, flexible, or generic way?
  我写了一个复杂的逻辑。 应用程序中是否存在类似的功能，也许以更易读，灵活或通用的方式实现了？
• If not, would I remember why I wrote this code in a week? If the answer is no, I probably want to change the code or comment it. The person reviewing the PR should have some context into why I made that decision.
  如果没有，我会记得为什么要在一周内编写这段代码吗？ 如果答案是否定的，我可能想要更改代码或对其进行注释。 审查PR的人应该对我做出该决定的原因有一些了解。
• Make sure your code is passing linting and tests before giving it to anyone else.
  在将代码提供给其他任何人之前，请确保您的代码通过了lint和测试。
• Am I repeating myself? Can I encapsulate the logic I’m repeating into a function?
  我在重复自己吗？ 我可以将要重复的逻辑封装到一个函数中吗？
• If this was someone else’s code that I was reviewing, what comments would I make? What would I want to change to make it more straight-forward?
  如果这是我正在检查的其他人的代码，我将发表哪些评论？ 我想改变什么使其更加简单明了？

Look at your code with a fresh set of eyes (maybe the next day). Is there specific logic bleeding into components that shouldn’t be? Is your component handling business logic that should go into a container?

用新的眼光看一下您的代码(也许第二天)。 是否有特定的逻辑渗入了不应该存在的组件中？ 您的组件正在处理应该放入容器的业务逻辑吗？

Additionally, good self code review saves time and money for the company. It’s way cheaper for you to find your own bugs and fix them yourself rather than having someone else find them two days later.

此外，良好的自我代码审查可以为公司节省时间和金钱。 对于您来说，找到自己的错误并自己进行修复比在两天后让其他人发现它们要便宜得多。

Last thing about reviewing your code. Touch and click EVERYTHING that you worked on. I want the code I send to anyone to be super hard to break. If they click a new page and get a big error or white screen of death it shows that I haven’t really reviewed my work. Grep for the code you edited and really make sure you didn’t break something else with your addition to a shared component.

关于检查代码的最后一件事。 触摸并单击您所做的所有操作。 我希望我发送给任何人的代码都很难破解。 如果他们单击一个新页面并出现大错误或白屏死机，则表明我还没有真正审查我的工作。 Grep提供您编辑的代码，并确保添加共享组件后不会破坏其他功能。

It might seem silly, but large code bases are complex and you might not realize you break something until you do.

这看起来很愚蠢，但是大型代码库很复杂，您可能直到意识到才可能破坏某些东西。

Seriously, you don’t want to see the first draft of this blog post :)

严重的是，您不想看到此博客文章的初稿：)

没有什么是魔术 (Nothing is magic)

There’s usually a good reason for why code has been LGTM’ed (approved and in the code base). If you don’t understand how it works, spend some time figuring it out. Log stuff, break stuff, look at some documentation of functions and patterns that were used.

通常有很好的理由解释为什么代码已通过LGTM审批(已批准并且在代码库中)。 如果您不了解它的工作原理，请花一些时间来解决它。 记录日志，分解日志，查看所用功能和模式的一些文档。

Could you tell your rubber duck how it worked? If you’re still unsure, ask some questions about specific gaps in your understanding.

你能告诉你橡皮鸭如何工作吗？ 如果您仍然不确定，请问一些有关您理解上的具体差距的问题。

进行大量调试，轻松调试 (Get comfortable debugging, since you do it a lot)

To debug is to understand the underlying problem in the functionality of your code and then solve the bug. You need to understand how the thing works to figure out why it’s not working in the first place. Being able to utilize the browser’s debugging tools is going to make your life and job way easier. The debugger and console methods are your friends.

调试是要了解代码功能中的潜在问题，然后解决该错误。 您需要了解事物的工作原理，以弄清为什么它不能首先发挥作用。 能够利用浏览器的调试工具将使您的生活和工作方式更加轻松。 调试器和控制台方法是您的朋友。

Some helpful resource that I found:

我发现了一些有用的资源：

• CSS Tricks on Debugging

  CSS调试技巧

• Front-End Masters Debugging (It’s paid but pretty good)

  前端大师调试 (已付费，但还算不错)

Pro-tip: console.log output can be stylized using CSS. This makes log you want to see easier to identify.

专家提示： console.log输出可以使用CSS进行样式化。 这使您希望查看的日志更易于识别。

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

追踪数据 (Follow the Data)

This came up over and over again, because admittedly it was a mistake I kept making. It’s something I got better at, but still needs work.

这件事一遍又一遍，因为我承认这是我一直犯的错误。 这是我比较擅长的事情，但仍然需要工作。

A big portion of software development involves the manipulation of data into a format so that a user can get actionable insight from it or update it on their own.

软件开发的很大一部分涉及将数据处理成某种格式，以便用户可以从中获得可行的见解或自行更新。

Applications with a uni-directional data flow and a global state have a direct line of data to follow. All that data is coming from somewhere. Once you find out where it’s coming from it’s easier to debug.

具有单向数据流和全局状态的应用程序具有直接的数据线。 所有这些数据都来自某个地方。 一旦找到问题的根源，就可以更轻松地进行调试。

隔离您的问题，然后将其集成到您正在处理的问题中 (Isolate your problems then integrate them into what you’re working on)

Codepen.io is a close friend of mine, and it should be yours too. When I can’t figure out what’s causing the issue, I make a simple version of what I’m building. I make sure it works, and then integrate it into my development environment. It’s easier to figure out what might be breaking your UI in a stripped down environment.

Codepen.io是我的密友，也应该属于您。 当我无法弄清是什么原因导致的问题时，请对要构建的内容进行简单的描述。 我确保它可以工作，然后将其集成到我的开发环境中。 找出在精简环境中可能破坏UI的内容更容易。

考虑该功能应该如何工作 (Think about how the functionality should work)

Writing down how something should work from a 30,000ft level and then from a technical level has helped me understand what I should be building, how I should be building it, and helps mitigate pit falls. If I can’t explain how the thing I’m building works (from a high and low level) I’m doing myself a disservice. Without a plan, I’m going to be doing a lot of wheel spinning in the very near future.

写下从30,000英尺的高度到技术高度的某个东西应该如何工作，这帮助我了解了我应该建造的东西，应该如何建造的东西，并有助于减轻坑坑洼洼的情况。 如果我不能解释我正在建造的东西是如何工作的(从高低两方面)，那我就对自己不利。 如果没有计划，我将在不久的将来进行很多车轮旋转。

Additionally, I can refer back to what I wrote or show someone what I’m thinking which helps reduce miscommunication.

此外，我可以参考自己写的内容，或者向别人展示我的想法，这有助于减少误解。

拥抱斗争 (Embrace the struggle)

After 10,000 hours of struggling at work, you’ll be way better at struggling through and solving problems. You’re going to have to do it regardless, so enjoying the experience is going to make your day-to-day much, much better. Laugh at yourself a bit and try to really break down the problem. You’ll get there, even if you need a little extra help.

经过10,000个小时的工作奋斗，您会更好地解决和解决问题。 无论如何，您都必须这样做，因此，享受体验将使您的日常工作变得越来越好。 嘲笑自己一点，尝试真正解决问题。 即使您需要一点额外的帮助，您也会到达那里。

接受建设性的批评并不断对其进行迭代 (Take constructive criticism and constantly iterate on it)

Your teammates want you to do better. Senior developers want to make you a stronger developer. Act on their advice even if you don’t initially understand why they’re telling you to do it. There’s never just one person who knows everything. Chat it up.

您的队友希望您做得更好。 高级开发人员希望使您成为更强大的开发人员。 即使您最初不了解他们为何要您这样做，也要根据他们的建议采取行动。 从来没有一个人什么都知道。 聊聊吧。

慢慢来 (Take your time)

Rushing through your work causes back and forth, lots of confusion, and additional frustration. My boss would rather see better code later than bad code sooner. I mean, wouldn’t we all?

匆匆忙忙地工作会导致来回往返，造成很多混乱和更多的挫败感。 我的老板宁愿迟见更好的代码，也不愿早见坏代码。 我的意思是，不是所有人吗？

在工作之外继续学习 (Continue learning outside of work)

As much as I learn on the job, I still want to continue to learn new things outside of just working on our code base. That might be picking up Python, building a bot, working through a video series, or working on a personal project. I made a board with Zenhub + Github to track where I’m at and what I’ve committed to for the month. Keeping a general goal for the month has forced me to continue learning, building, and yes, blogging on my own time.

尽管我在工作中学到了很多东西，但我仍然希望继续学习新知识，而不仅仅是在我们的代码库上工作。 这可能是选择Python，构建机器人，观看视频系列或进行个人项目。 我与Zenhub + Github一起制作了一个董事会，以跟踪我的位置以及本月的承诺。 维持一个月的总体目标迫使我继续学习，建设，是的，自己写博客。

翻译自: https://www.freecodecamp.org/news/9-months-into-a-software-engineering-role-this-is-what-i-learned-823230e4be9a/

软件工程与软件测试基础知识