基于任务编程

by Justin Fuller

贾斯汀·富勒(Justin Fuller)

如何理解任何编程任务 (How to understand any programming task)

The day has finally arrived. Is it your first day on your job, or have you been doing this for ten years? It doesn’t matter. We all eventually find ourselves with a task that we simply do not understand.

一天终于到了。这是您上班的第一天，还是已经十年了？没关系最终，我们所有人都会发现自己根本无法理解的任务。

So what should you do? Should you just get started and hope it works? Should you immediately tell your boss that you can’t do this because you don’t understand?

那你该怎么办？您是否应该开始并希望它能起作用？您是否应该立即告诉老板您因为不了解而无法执行此操作？

I imagine that you know the answer is neither!

我想您知道答案不对！

In programming, as with any other profession, I have found that it’s almost impossible to go through a week (and sometimes not even a day) without finding some problem that I don’t understand.

在编程方面，与其他任何职业一样，我发现几乎不可能一周(有时甚至一天)都找不到我不理解的问题。

But don’t fret! I have great news. Not only can you fix this problem, but it can also be a good thing.

但是不要担心！我有个好消息您不仅可以解决此问题，而且还是一件好事。

It means that in some way you are expanding your skill and knowledge beyond what you’ve done and known before.

这意味着您将以某种方式将自己的技能和知识扩展到您以前已经做过的事情和已知的事情之外。

In the next few paragraphs I’m going to detail how you can bridge the gap between the requirements you’ve been handed, and the knowledge you need to complete the task you’ve been given.

在接下来的几段中，我将详细介绍如何弥合已处理的需求与完成已完成的任务所需的知识之间的差距。

关于“要求” (About ‘requirements’)

You may have noticed that I used the word “requirements”. That word might have certain connotations depending on where you work.

您可能已经注意到，我使用了“要求”一词。根据您在哪里工作，该词可能具有某些含义。

In my experience, big companies love requirements and small companies sometimes “don’t do requirements”. I think this is perfectly fine for our purposes here.

以我的经验，大公司喜欢需求，而小公司有时“不做需求”。我认为这对于我们这里的目的而言是完全可以的。

That’s because in the end all we’re doing as software engineers is solving problems.

这是因为最终，作为软件工程师，我们要做的就是解决问题。

You could receive an extensive one hundred page report on how to solve that problem (I once had an hour long meeting about the text for a button). Or maybe your CEO will meander over to your desk and casually ask if you can solve the problem by Friday.

您将收到一份有关如何解决该问题的详尽的一百页报告(我曾经有一个小时的会议讨论按钮文字)。或者，也许您的首席执行官会弯腰到您的办公桌前，随便问您是否可以在星期五之前解决问题。

Either way — you’ve been given a task, and you need to be sure you fully understand that problem in order to address it correctly!

无论哪种方式-您都已获得任务，并且需要确保您完全了解该问题才能正确解决！

关于步骤 (About the steps)

Not all of the steps given below are needed for every problem. Only the hardest problems to understand may require you to carefully proceed through all the steps that will be discussed in this article.

并非每个问题都需要下面给出的所有步骤。只有最难理解的问题可能需要您仔细进行本文将要讨论的所有步骤。

Many of the questions may not be answerable through the requirements that you’ve been given, or through your personal experience alone.

根据给出的要求或仅凭个人经验，许多问题可能无法回答。

You may have to ask other developers, your team lead, product owner, business analyst, or even your grandma. Maybe you’ll have to ask all of them by the time you’re done!

您可能需要问问其他开发人员，您的团队负责人，产品负责人，业务分析师，甚至您的祖母。也许您需要在完成时问所有这些问题！

That’s fine though. It means you’ll be taking scattered knowledge and condensing it to reside in one place. That place is in yourself and now you will be able to produce the best possible result!

没关系。这意味着您将掌握分散的知识并将其浓缩到一个地方。那个地方在你自己，现在你将能够产生最好的结果！

A final warning before you learn the steps: don’t over-formalize this process. The point here is to help you quickly understand a problem. It shouldn’t create barriers or red tape! Instead it should provide you with a systematic plan to tackle a problem you don’t understand.

学习步骤之前的最后警告：请勿过度规范此过程。这里的重点是帮助您快速理解问题。它不应造成障碍或繁文tape节！相反，它应该为您提供系统的计划，以解决您不了解的问题。

第一步：分析任务 (The first step: Analyzing the task)

In this step, you will seek to understand what you’ve been asked to do. You’re not trying to figure out how to do it yet!

在这一步中，你会设法了解你被要求做什么。您还没有想出如何做！

The distinction here is important. It can be dangerous to jump straight in to implementation without thinking through all the consequences, or worse, without identifying exactly what it is you’ve been asked to do.

这里的区别很重要。如果不仔细考虑所有后果，或者直接弄清楚要求您执行的操作，直接进入实施可能会很危险。

分类任务 (Classify the task)

To classify a task means to determine what kind of work you’ll be doing to solve this problem. Here are some examples of types of tasks:

对任务进行分类意味着确定要解决该问题的工作类型。以下是一些任务类型的示例：

Bug fix错误修复
New feature新功能
New application新申请
Research Assignment研究任务
Performance improvement性能改进

Remember that these are not all the possible options.

请记住，这些并不是所有可能的选择。

The goal here is to determine what kind of work you are expected to do. This is important because it has a direct effect on what work you do.

这样做的目的是要确定你期望做什么样的工作。这是重要的，因为它有什么工作，你做一个直接的影响。

This step is particularly important for vague requirements. An example of a vague requirement is: “We need a way to purge our clients’ caches after an update to the website.”

对于模糊的要求，此步骤特别重要。一个模糊要求的例子是：“我们需要一种在网站更新后清除客户缓存的方法。”

There can be a few possible interpretations.

可能有几种解释。

You need to immediately implement some cache purging mechanism so that clients always see the latest updates.您需要立即实现某种缓存清除机制，以便客户端始终可以看到最新更新。
You need to research all the ways that clients’ caches are stored and determine the best way or ways to bust those caches after every update of the website.您需要研究存储客户端缓存的所有方式，并确定在每次网站更新后消除这些缓存的最佳方法。
The clients’ caches already should be being cleared and you need to find and fix the bug that is preventing them from clearing.应该已经清除了客户端的缓存，您需要找到并修复阻止其清除的错误。

At this point, if you aren’t absolutely sure which meaning is being used, you should ask for clarification before proceeding.

在这一点上，如果您不确定要使用的是什么意思，则应在进行操作之前要求澄清。

用一两个简单的句子说明任务是什么。 (State what the task is in one or two simple sentences.)

Summarize the complicated requirements as if you’ve been asked what you are working on today. Maybe it won’t be that simple, but you should be able to boil it down to a sentence or two.

总结复杂的需求，就像您被问到今天在做什么一样。也许不是那么简单，但是您应该可以将其简化为一两个句子。

If you can’t summarize the task it probably means you are going to need to split it up into multiple tasks. So essentially this step becomes a litmus test to determine if you’ve organized your tasks into small enough chunks.

如果您无法概括任务，则可能意味着您需要将其拆分为多个任务。因此，从本质上讲，此步骤成为确定您是否将任务组织成足够小的块的试金石。

Here’s a good example of a summary: “When we update the site, we append a unique number to the files so that the browser knows it needs to use the latest code.”

这是一个很好的摘要示例：“当我们更新站点时，我们在文件中附加一个唯一的数字，以便浏览器知道它需要使用最新的代码。”

This task passes the simplicity litmus test and you probably don’t need to create multiple tasks.

该任务通过了简单性石蕊试纸，您可能不需要创建多个任务。

A bad example might look like: “When we update the site we append a unique number to the files so that the browser knows it needs to use the latest code. We also have to send a message to our CDN letting it know that it needs to update the files. Also the IOS and Android apps will need to have an update sent to the app store. Also…”

一个不好的例子可能看起来像： “当我们更新站点时，我们在文件上附加一个唯一的数字，以便浏览器知道它需要使用最新的代码。我们还必须向CDN发送一条消息，告知它需要更新文件。此外，IOS和Android应用程序也需要将更新发送到应用程序商店。也…”

This one clearly fails the test. There’s a lot of work to do and it may need to be identified and tracked separately.

这显然没有通过测试。有很多工作要做，可能需要分别进行识别和跟踪。

概述主要部分 (Outline the major parts)

In whatever form is most convenient for you, you should now make a list of the major things that must be done.

现在，以任何一种最方便的形式，您都应该列出必须要做的主要事情。

These should still be very simple summaries of each major step.

这些仍然应该是每个主要步骤的非常简单的摘要。

These should not be a step by step or detailed guide of how to fix the issue.

这些不应该是一步步或如何解决问题的详细指南。

Remember that you are still analyzing the task you were given. I would recommend writing these down somehow. I personally record them in my Notes app.

请记住，您仍在分析任务。我建议以某种方式写下这些。我个人将它们记录在Notes应用程序中。

Our caching task is very simple and may not actually need an outline. For this example we’ll consider a more complex issue.

我们的缓存任务非常简单，实际上可能不需要轮廓。对于此示例，我们将考虑一个更复杂的问题。

Our next task is a new feature: “Each user should be shown a targeted advertisement for an internal product. This ad should be tailored to fit their individual needs based on the data we have collected.”

我们的下一个任务是一项新功能：“应该向每个用户展示针对内部产品的广告。该广告应根据我们收集的数据量身定制，以满足其个人需求。”

To outline the major parts you will need to think clearly about what each part of the requirement will have you do.

要概述主要部分，您需要清楚地考虑需求的每个部分将要做什么。

Our current advertisements will need to be broken down in such a way that they can correlate to some specific user metric.我们当前的广告将需要以可以与某些特定用户指标相关联的方式进行细分。
There will need to be a way for our marketing team to map new advertisements to a piece or pieces of user data (without coding!)我们的营销团队将需要一种将新广告映射到一条或多条用户数据的方式(无需编码！)
The system will need to aggregate metrics about a user that are relevant to our advertisements.系统将需要汇总与我们的广告相关的用户指标。
Finally, you need to create some kind of system that receives a user id and outputs an advertisement.最后，您需要创建一种接收用户ID并输出广告的系统。

The beauty of a list like this is that it can be used to quickly verify with your team or boss! So in this example, maybe you’ve run it by your team lead and he decided that there needs to be one more major piece:

这样的清单的优点在于可以用来与您的团队或老板快速核实！因此，在此示例中，也许您是由团队领导来运行的，而他认为还需要再做一个主要工作：

Users should be able to tell us when they don’t want to see certain ads any more.当用户不想再看到某些广告时，他们应该可以告诉我们。

Because after all, we don’t want to annoy our beloved users! By taking the time to think about our task for just a couple minutes, we’ve saved hours or days of pain later by identifying and planning for an important task before getting started with coding.

因为毕竟，我们不想惹恼我们心爱的用户！通过花几分钟的时间思考我们的任务，通过在开始编码之前确定并计划一项重要任务，我们节省了数小时或数天的痛苦。

Before we move on, I want to address a possible criticism that you might have.

在继续之前，我想解决您可能提出的批评。

You might be thinking: “In a proper business this is the type of work that should be done before requirements ever reach the developer”, and I definitely agree with you!

您可能会想：“在适当的业务中，这是在需求到达开发人员之前应该完成的工作类型”，我绝对同意您的观点！

However, we sadly don’t live in a perfect world. Sometimes requirements aren’t always completely fleshed out before they get to a developer. This means we must all do our best to properly evaluate the requirements before development starts.

但是，可悲的是我们没有生活在一个完美的世界中。有时，在到达开发人员之前，需求并不总是完全充实。这意味着我们都必须尽最大努力在开发开始之前正确评估需求。

定义一个或多个您要解决的问题。 (Define the problem or problems that you are trying to solve.)

Answer the question, “why will someone use this?”, or “what actual or perceived real world problem am I trying to fix?”

回答以下问题：“为什么会有人使用它？”或“我要解决的实际或感知现实问题是什么？”

Hopefully the answer is obvious. For our cache example you could say, “users will always see the latest updates.” For the advertisement example, “users will see relevant ads instead of ads they don’t care about.”

希望答案是显而易见的。对于我们的缓存示例，您可以说：“用户将始终看到最新更新。” 对于广告示例，“用户将看到相关的广告，而不是他们不在乎的广告。”

If the answer isn’t obvious then it’s probably time to ask someone why you are doing this task! Asking this question will lead to either you having a clearer understanding of the task at hand, or it will lead to a re-think of what you’ve been asked to do.

如果答案不明显，那么可能是时候问别人为什么要执行此任务了！提出这个问题将使您对手头的任务有更清晰的了解，或者使您重新考虑要执行的任务。

Hopefully you see the benefits to either of those answers! A deeper understanding of the problem and purpose will allow you to make decisions in your implementation that actually serve the business goals. Identifying bad solutions or problems that don’t make sense will avoid wasted effort on work that would never solve a problem in the end.

希望您能从这些答案中受益！对问题和目的的更深入了解将使您能够在实现中做出实际服务于业务目标的决策。找出不合理的不良解决方案或问题将避免浪费大量的工作，而这些工作最终将永远无法解决问题。

第二步：解释和评估需求 (The second step: Interpreting and evaluating the requirements)

At this point you should have an understanding of what it is that you will be doing and why you are doing it.

在这一点上，您应该了解将要做什么以及为什么要这样做。

Your next step will be to understand the details of what you are doing, how you are expected to do it, and why you are doing it that way.

下一步将是了解您正在做的事情，应该怎么做以及为什么要这样做的细节。

阐明与您的任务相关的所有重要术语。 (Clarify all the important terms related to your task.)

You may find that this step is more important if you are a new developer on a team or if you work in a large company. Both of those situations make it more likely that you will find unknown terms in your requirements.

如果您是团队中的新开发人员或在大型公司工作，则可能会发现此步骤更为重要。两种情况都使您更有可能在需求中找到未知术语。

Terms can be business terms, like the names of products, customers, or processes. They can also be development terms like names of tools, applications, models, services, or libraries.

术语可以是商业术语，例如产品，客户或流程的名称。它们也可以是开发术语，例如工具，应用程序，模型，服务或库的名称。

You must be sure to understand all the important terms, without any vagueness, so that you can be certain you are implementing your task correctly.

您必须确保毫无疑问地理解所有重要术语，以便可以确定自己正确地执行了任务。

You might understand that you need to create a way to access the aggregated user information, but do you understand what it means to add it to the “dao”?

您可能会理解，您需要创建一种访问汇总的用户信息的方法，但是您是否了解将其添加到“ dao”的含义？

You might understand that you need to format the advertisement data, but do you understand what the “MADF” (Marking advertisement data feed) is?

您可能会了解需要格式化广告数据，但是您了解“ MADF”(标记广告数据供稿)是什么吗？

Neither do I.

我也不。

This is why you must identify and define all the important terms. You have a greater chance of implementing the task incorrectly if you get the definitions wrong.

这就是为什么您必须识别并定义所有重要术语的原因。如果您弄错了定义，则更有可能错误地执行任务。

确定应如何完成任务 (Identify how the task should be done)

At this point you should now begin to look at how the task should be done. This step can vary widely depending on where you work and the particular task you’ve been given.

此时，您现在应该开始研究如何完成任务。根据您在哪里工作以及完成的特定任务，此步骤可能会有很大差异。

On some teams you won’t be told how to implement requirements, you’ll just be told what functionality you should end up with.

在某些团队中，不会告诉您如何实施需求，而只会告诉您最终应该使用什么功能。

Others will detail every step you should take.

其他人将详细说明您应该采取的每个步骤。

Most likely your experience falls somewhere in the middle.

您的经历很可能落在中间。

If your team hasn’t given you instructions then you can’t do much on this step. If you have been given instructions, then at this point you’ll want to begin to become familiar with the steps you’ll need to take.

如果您的团队没有给您指示，那么您将无法在此步骤中做很多事情。如果已获得指示，那么此时您将要开始熟悉需要采取的步骤。

This step seems pretty obvious, but the order it comes in is something you should pay special attention to.

这个步骤似乎很明显，但是您应该特别注意它的出现顺序。

The natural inclination can be to dive into all the details of the task before ensuring that the purpose of the task is understood.

自然的倾向是在确保了解任务的目的之前先深入研究任务的所有细节。

Since you’ve taken the time to understand your task first, you will now have a clearer goal in mind when evaluating the steps you need to take.

由于您已经花了一些时间首先了解自己的任务，因此在评估需要采取的步骤时，您现在会想到一个更清晰的目标。

确定问题是否解决 (Determine if the problems were solved)

This is where the analysis stage and the interpretation stage come together. In the analysis stage you focused on the big picture goals and outcomes, the what and why.

这是分析阶段和解释阶段结合在一起的地方。在分析阶段，您将重点放在总体目标和结果，原因和原因上 。

In the interpretation step you focused on the details, the how.

在解释步骤中，您将重点放在细节， 方法上 。

The reason it’s called interpretation and evaluation is that you will now compare the how to the what and the why. You interpret the details by considering the bigger picture. You will evaluate the details and determine if the original problem was solved.

之所以称为解释和评估，是因为您现在将比较方法与内容和原因。您通过考虑全局来解释细节。您将评估详细信息并确定是否解决了原始问题。

Ask yourself: Will the steps I’ve been given result in the outcome that your task was intended to create? Will this outcome actually solve the original problem?

问自己：我得到的步骤是否会导致您打算创建任务的结果？这样的结果会真正解决原来的问题吗？

If you feel confident that all the problems are solved, and all the details make sense, you are ready to begin your work! Otherwise, you must move to the third stage to resolve any conflicts.

如果您有信心解决所有问题，并且所有细节都说得通，那么您就可以开始工作了！否则，您必须进入第三阶段以解决所有冲突。

第三步：认真思考 (The third step: Think critically)

At this stage you should confidently be able to state that you understand the problem and the solution. The very last step is to make sure that you have the right solution.

在此阶段，您应该自信地声明您已了解问题和解决方案。最后一步是确保您拥有正确的解决方案。

In order to create the best possible product we should all feel like we have the responsibility to speak up when something just doesn’t make sense.

为了创造出最好的产品，我们都应该感到有责任在没有意义的时候大声疾呼。

On the other hand, we don’t want to disagree out of turn. You shouldn’t say something is wrong because “it feels wrong” or because “I don’t like it”. You must have concrete and well thought out reasons.

另一方面，我们不想不同意。您不应该因为“感觉不对”或因为“我不喜欢”来说错了。您必须有具体且经过深思熟虑的原因。

So lets lay down some ground rules about disagreements.

因此，让我们为分歧制定一些基本规则。

知道何时不同意 (Know when to disagree)

Don’t disagree until you understand fully.在您完全理解之前，请不要不同意。

Never say that something is wrong until you are absolutely sure you understand what you are disagreeing with.

除非您完全确定自己了解不同意的内容，否则请不要说出问题。

If you can’t confidently state the problem and the intended solution, you shouldn’t disagree. If you haven’t verified your understanding, you shouldn’t disagree. Only when you know you have the most complete understanding possible should you begin to disagree.

如果您不能自信地说明问题和预期的解决方案，则不应不同意。如果您尚未验证自己的理解，则不应反对。只有当您知道自己拥有最全面的理解时，您才开始不同意。

If you find that you don’t have all the information you need, then it might be time to stop and revisit any of the previous steps before you tell someone that the requirements are wrong.

如果发现您没有所需的所有信息，那么可能是时候停止并重新访问之前的任何步骤，然后再告诉某人要求是错误的。

Don’t disagree over subjective matters. Focus on actual potential problems.不要在主观上意见分歧。关注实际的潜在问题。

“I don’t like how this is done” is subjective. “This will cause performance issues because of the number of operations involved.” is an objective reason. Other examples of subjective reasons might include, “This isn’t how I’ve done it elsewhere” and “I would have designed this solution slightly differently, but only because of personal preferences.”

“我不喜欢这样做”是主观的。 “由于涉及的操作数量众多，这将导致性能问题。” 是客观原因。主观原因的其他示例可能包括：“这不是我在其他地方所做的事情”和“我会稍微不同地设计此解决方案，但这仅是出于个人喜好。”

Have well reasoned explanations of your disagreements ready to be presented.准备好合理地解释您的分歧。

If you can’t explain why something is wrong, can you really say that you actually know it’s wrong? I would suggest writing down the reasons why something is wrong and what can be done to fix it.

如果您无法解释为什么出问题了，您是否可以说出您确实知道出了问题？我建议写下错误原因以及可以解决的方法。

Alternatively, if you don’t have a solution to fix it, state clearly at the beginning that you don’t know.

或者，如果您没有解决方案，请在开始时清楚说明您不知道的地方。

Be careful about when you disagree with others. The bulk of your time should be spent on understanding and listening before you disagree.

当您不同意别人时要当心。在您不同意之前，应将大部分时间用于理解和倾听。

If you followed all the steps up until this point it’s very likely that you have a good understanding. But take great care to keep an open mind that you may have missed something!

如果您按照所有步骤进行操作，直到现在为止，您很有可能已经了解了。但是请务必保持开放的态度，以防您可能错过了某些东西！

I like to start conversations by saying, “I’m not disagreeing with you, I just don’t understand.” Later comes the disagreement if necessary, but hopefully never before understanding.

我喜欢通过说“我不同意您，我只是不理解”来开始对话。如有必要，稍后会出现分歧，但希望永远不要理解。

知道如何不同意 (Know how to disagree)

In order to make sure we disagree objectively, here are a few measures that will help you determine if your disagreement is valid.

为了确保我们客观地不同意，这里有一些措施可以帮助您确定您的异议是否有效。

Objective disagreements do one or more of the following:

客观分歧会执行以下一项或多项措施：

Show that the solution is uninformed.证明解决方案是无知的。
Show that the solution is misinformed.证明解决方案是错误的。
Show that the problem or solution is illogical.表明问题或解决方案不合逻辑。
Show that the solution is incomplete.显示解决方案不完整。

To be uninformed is not an insult, but instead it means that information was lacking when a solution was created. Perhaps they did not know about a system that currently exists and can perform the actions that are needed.

不知情不是侮辱，而是意味着在创建解决方案时缺少信息。也许他们不了解当前存在的系统并且可以执行所需的操作。

To be misinformed means that the solution came from incorrect information.

被误导意味着解决方案来自错误的信息。

In this case they might think an existing system does something that it actually does not. For example, maybe the SEO (search engine optimization) team asked you to have Google indexed a logged in page on your application. Google can’t do that. They were misinformed about what Google’s crawler does.

在这种情况下，他们可能会认为现有系统确实会做一些实际上没有做的事情。例如，SEO(搜索引擎优化)团队可能要求您让Google将您应用程序中的登录页面编入索引。 Google无法做到这一点。他们对Google的抓取工具的操作不了解。

An illogical problem or solution is one that simply does not make sense. As a developer I think a common illogical request you might see is for one feature that could break another feature. It could be considered illogical to do that because it would hurt, rather than help.

不合逻辑的问题或解决方案是根本没有道理的。作为一名开发人员，我认为您可能会看到的常见不合逻辑的要求是，该功能可能破坏另一功能。这样做可能被认为是不合逻辑的，因为这会伤害而不是帮助。

A solution being incomplete may actually be intended. In software development we often try to start by making an MVP (minimum viable product). This means that we may, at first, purposely leave out functionality that isn’t absolutely necessary.

实际上可能是不完整的解决方案。在软件开发中，我们经常尝试从制作MVP(最小可行产品)开始。这意味着我们一开始可能会故意剔除并非绝对必要的功能。

Instead you should only consider a solution to be incomplete if it doesn’t solve the immediate problem that you’ve been asked to fix, or if the steps provided aren’t sufficient to create a working product or feature.

相反，如果解决方案不能解决您被要求立即解决的直接问题，或者提供的步骤不足以创建有效的产品或功能，则应仅考虑解决方案不完整。

摘要 (Summary)

Remember, don’t over-formalize this process. It should be quick and probably consist of jotting down a few thoughts in your Notes app. Then it could possibly lead to a few conversations with your coworkers to clarify what you’re supposed to be doing. That’s all!

请记住，不要过分规范化此过程。它应该很快，并且可能包括在Notes应用程序中记下一些想法。然后可能会导致与您的同事进行一些对话，以弄清您应该做什么。就这样！

Here’s a simplified list of the steps:

这是步骤的简化列表：

Step 1 — Analyze

第1步-分析

Classify分类
Summary摘要
Outline大纲
Define the problem定义问题

Step 2 — Interpret and Evaluate

第2步-解释和评估

Clarify terms澄清术语
Identify the tasks确定任务
Determine if the problem will be solved确定问题是否会解决

Step 3 — Think Critically

第3步-认真思考

Know when to disagree知道何时不同意
Know how to disagree知道如何不同意

Hi, I’m Justin Fuller. I’m so glad you read my post! I need to let you know that everything I’ve written here is my own opinion and is not intended to represent my employer in any way. All code samples are my own, and are completely unrelated to Bank Of America’s code.

嗨，我叫Justin Fuller。我很高兴您阅读我的帖子！我需要让您知道，我在这里写的所有内容都是我自己的观点，并不以任何方式代表我的雇主。所有代码示例都是我自己的，并且与美国银行的代码完全无关。

I’d also love to hear from you, please feel free to connect with me on LinkedIn, Github, or Medium. Thanks again for reading!

我也希望收到您的来信，请随时通过LinkedIn ， Github或Medium与我联系。再次感谢您的阅读！

翻译自: https://www.freecodecamp.org/news/how-to-understand-any-programming-task-aea41eabe66e/