积跬步,至千里
精前端,通全栈

如何理解分配给你的编程任务

这一天终于来了。这是你工作的第一天,还是你已经这样做了十年?没关系。我们最终都发现自己处于一项我们根本无法理解的任务中。

那你该怎么办?你应该刚开始并希望它有效吗?你是否应该立即告诉你的老板你不能这样做,因为你不明白?

我想你知道答案都不是!

在编程方面,和任何其他职业一样,我发现如果没有找到一些我不理解的问题,几乎不可能经历一周(有时甚至不是一天)。

但不要担心!我有个好消息。你不仅可以解决这个问题,而且也可以是一件好事。

这意味着,在某种程度上,您正在扩展您的技能和知识,超越您之前所做和已知的。

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

关于'要求'

您可能已经注意到我使用了“要求”这个词。根据你的工作地点,这个词可能有某些含义。

根据我的经验,大公司喜欢要求,小公司有时“不做要求”。我认为这对我们这里的目的来说非常好。

那是因为最终我们所做的一切都是软件工程师在解决问题。

您可以收到关于如何解决该问题的广泛的一百页报告(我曾经有一个小时的会议关于按钮的文本)。或者也许你的首席执行官会蜿蜒到你的办公桌前随便询问你是否可以在星期五之前解决问题。

无论哪种方式 - 你已经完成了任务,你需要确保你完全理解这个问题才能正确解决它!

关于步骤

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

许多问题可能无法通过您提供的要求或仅通过您的个人经验来回答。

您可能需要询问其他开发人员,您的团队负责人,产品负责人,业务分析师甚至您的祖母。也许你必须在完成之前问问所有人!

那很好。这意味着你将利用分散的知识并将其凝聚在一个地方。那个地方在你自己,现在你将能够产生最好的结果!

在您了解步骤之前的最后警告:不要过度正式化此过程。这里的重点是帮助您快速了解问题。它不应该制造障碍或繁文缛节!相反,它应该为您提供系统的计划来解决您不理解的问题。

第一步:分析任务

在这一步中,你会设法了解什么你被要求做的。你不是想弄清楚怎么做!

这里的区别很重要。在没有考虑所有后果的情况下直接进入实施可能是危险的,或者更糟糕的是,没有确切地确定你被要求做什么。

对任务进行分类

对任务进行分类意味着确定您将要采取哪种工作来解决此问题。以下是一些任务类型的示例:

  • 错误修复
  • 新功能
  • 新的申请
  • 研究任务
  • 性能改进

请记住,这些并非所有可能的选择。

这里的目标是确定您应该做什么样的工作。这是重要的,因为它有一个直接的影响是什么工作,你做的。

这一步骤对于模糊的要求尤为重要。模糊要求的一个例子是:“我们需要一种方法来在网站更新后清除客户的缓存。”

可能有一些可能的解释。

  1. 您需要立即实施一些缓存清除机制,以便客户端始终可以看到最新的更新。
  2. 您需要研究存储客户端缓存的所有方法,并确定在每次更新网站后破坏这些缓存的最佳方法。
  3. 客户端的缓存已经被清除,您需要找到并修复阻止它们清除的错误。

此时,如果您不完全确定使用了哪种含义,则应在继续之前要求澄清。

用一两个简单的句子说明任务是什么

总结复杂的要求,好像你被问到你今天在做什么。也许它不会那么简单,但你应该把它煮到一两句话。

如果您无法总结任务,则可能意味着您需要将其拆分为多个任务。因此,基本上这一步将成为一个试金石,以确定您是否已将任务组织成足够小的块。

以下是摘要的一个很好的例子:“当我们更新网站时,我们会在文件中附加一个唯一的编号,以便浏览器知道它需要使用最新的代码。”

此任务通过了简单的试金石,您可能不需要创建多个任务。

一个不好的例子可能是这样的:“当我们更新网站时,我们会在文件中附加一个唯一的编号,以便浏览器知道它需要使用最新的代码。我们还必须向 CDN 发送消息,告知它需要更新文件。此外,IOS 和 Android 应用程序需要将更新发送到应用商店等…”

这个显然没有通过测试。有很多工作要做,可能需要单独识别和跟踪。

概述主要部分

无论哪种形式对您来说最方便,您现在应该列出必须完成的主要事项。

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

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

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

我们的缓存任务非常简单,实际上可能不需要大纲。对于这个例子,我们将考虑一个更复杂的问题。

我们的下一个任务是一个新功能:“每个用户都应该看到内部产品的目标广告。该广告应根据我们收集的数据量身定制,以满足其个人需求。“

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

  • 我们当前的广告需要以一种可以与某些特定用户指标相关联的方式进行细分。
  • 我们的营销团队需要有一种方法将新广告映射到一个或多个用户数据(无需编码!)
  • 系统将需要汇总与我们的广告相关的用户指标。
  • 最后,您需要创建一种接收用户ID并输出广告的系统。

这样的列表的美妙之处在于它可以用于与您的团队或老板快速验证!所以在这个例子中,也许你是由你的团队负责人运行的,他决定还需要一个主要部分:

  • 用户应该能够告诉我们他们何时不想再看到某些广告。

因为毕竟我们不想惹恼我们心爱的用户!通过花时间思考我们的任务只需几分钟,我们通过在开始编码之前识别和规划一项重要任务,节省了数小时或数天的痛苦。

在我们继续前进之前,我想解决一个可能存在的批评。

您可能会想:“在适当的业务中,这是在需求到达开发人员之前应该完成的工作类型”,我绝对同意您的看法!

但是,我们遗憾地生活在一个完美的世界里。有些需求在到达开发人员之前并不总是完全充实。这意味着我们必须尽力在开发之前正确评估需求。

定义您要解决的问题。

回答这个问题,“为什么会有人使用这个?”,或“我想解决的实际或感知的现​​实问题是什么?”

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

如果答案不明显,那么可能是时候问某人你为什么要做这个任务了!提出这个问题将导致您对手头的任务有更清楚的了解,或者会导致重新考虑您被要求做的事情。

希望你看到这些答案的好处!更深入地了解问题和目的将使您能够在实施中做出实际服务于业务目标的决策。找出不合理的错误解决方案或问题将避免在最终无法解决问题的工作上浪费精力。

第二步:解释和评估要求

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

您的下一步将是了解您正在做什么的细节,您希望如何做到这一点,以及您为什么这样做。

澄清与您的任务相关的所有重要术语。

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

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

您必须确保理解所有重要条款,不得含糊不清,这样您才能确定正确执行任务。

您可能了解您需要创建一种访问聚合用户信息的方法,但是您是否了解将其添加到“dao”意味着什么?

您可能理解需要格式化广告数据,但是您是否了解“MADF”(标记广告数据源)是什么?

我也不。(Neither do I.)

这就是您必须识别和定义所有重要术语的原因。如果定义错误,则更有可能错误地执行任务。

确定应该如何完成任务

此时,您现在应该开始研究应该如何完成任务。根据您的工作地点和您给出的特定任务,此步骤可能会有很大差异。

在一些团队中,您将不会被告知如何实现要求,您将被告知您最终应该使用哪些功能。

其他人会详述您应该采取的每一步。

很可能你的经历落在中间的某个地方。

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

这一步看起来非常明显,但它的顺序是你应该特别注意的。

在确保理解任务的目的之前,自然倾向可以深入到任务的所有细节中。

由于您已经花时间先了解您的任务,因此在评估您需要采取的步骤时,您现在将有一个更清晰的目标。

确定问题是否已解决

这是分析阶段和解释阶段结合在一起的地方。在分析阶段,你着眼于大局的目标和成果,在什么和为什么。

在解释步骤中,您如何专注于细节。

它被称为解释和评估的原因是,您现在将比较如何与原因和原因。您可以通过考虑更大的图片来解释细节。您将评估详细信息并确定原始问题是否已解决。

问问自己:我给出的步骤会导致您的任务打算创建的结果吗?这个结果真的会解决原来的问题吗?

如果您确信所有问题都已解决,并且所有细节都有意义,那么您就可以开始工作了!否则,您必须转到第三阶段以解决任何冲突。

第三步:批判性思考

在这个阶段,您应该自信地表明您了解问题和解决方案。最后一步是确保您拥有正确的解决方案。

为了创造出最好的产品,我们都应该感到有责任在没有意义的事情上说出来。

另一方面,我们不想反过来不同意。你不应该说出错是因为“感觉不对”,或者因为“我不喜欢它”。你必须有充分和深思熟虑的理由。

所以我们就分歧达成一些基本规则。

知道什么时候不同意

  • 在你完全理解之前不要不同意。

在你完全确定自己明白自己不同意之前,永远不要说出错了。

如果您无法自信地陈述问题和预期的解决方案,那么您不应该不同意。如果您尚未验证您的理解,那么您不应该反对。只有当你知道自己有最完整的理解时才开始不同意。

如果您发现自己没有所需的所有信息,那么在告诉某人要求错误之前,可能需要停止并重新访问上述任何步骤。

  • 不要在主观问题上存在分歧。关注实际的潜在问题。

“我不喜欢这样做”是主观的。“由于所涉及的操作数量,这将导致性能问题。”是客观原因。主观原因的其他例子可能包括,“这不是我在其他地方做过的事情”和“我本来会设计这个解决方案略有不同,但仅仅是因为个人偏好。”

  • 对你准备提出的分歧有充分的理由解释。

如果你无法解释为什么出了什么问题,你真的可以说你确实知道这是错的吗?我建议写下出现错误的原因以及可以采取哪些措施来解决问题。

或者,如果您没有解决方案来修复它,请在开头清楚地说明您不知道。

当你不同意他人时要小心。在您不同意之前,您的大部分时间都应花在理解和倾听上。

如果您按照所有步骤进行操作,那么您很可能对此有了很好的理解。但要小心保持开放的心态,否则你可能会错过一些东西!

我喜欢开始谈话时说:“我不是不同意你,我只是不明白。”如果有必要,后来会出现分歧,但希望之前从未理解过。

知道如何不同意

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

客观上的分歧会做以下一项或多项:

  • 显示解决方案不知情。
  • 表明解决方案被误导。
  • 表明问题或解决方案不合逻辑。
  • 表明解决方案不完整。

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

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

在这种情况下,他们可能会认为现有系统做的事情实际上并没有。例如,SEO(搜索引擎优化)团队可能会要求您让Google在您的应用程序上编入登录页面。谷歌不能这样做。他们被误导了Google的抓取工具。

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

实际上可能意图解决不完整的解决方案。在软件开发中,我们经常尝试制作MVP(最小可行产品)。这意味着我们首先可能故意遗漏不是绝对必要的功能。

相反,如果解决方案不能解决您被要求修复的直接问题,或者提供的步骤不足以创建工作产品或功能,那么您应该只考虑解决方案。

总结

请记住,不要过度正式化这个过程。它应该很快,可能包括在Notes应用程序中记下一些想法。然后它可能会导致与您的同事进行一些对话,以澄清您应该做的事情。就这样!

这是一个简化的步骤列表:

第1步 - 分析

  • 分类
  • 概要
  • 大纲
  • 定义问题

第2步 - 解释和评估

  • 澄清条款
  • 确定任务
  • 确定问题是否将得到解决

第3步 - 批判性思考

  • 知道什么时候不同意
  • 知道如何不同意

谢谢阅读!我很乐意听到你的消息。您是否拥有用于理解复杂编程任务的系统?你会从这个列表中添加或删除任何内容吗?请随意发表评论,分享您的想法。

赞(0) 打赏
未经允许不得转载:前端学堂 » 如何理解分配给你的编程任务

讨论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

前端实战学习群 学以致用,进步更快

demo演示立即加入

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏