为新软件开发人员解决问题

成为经验丰富的软件开发人员，并不意味着知道每个问题的解决方案，也不意味着要了解整个系统及其众多优势。

我知道了。 感觉您应该知道这些东西很冷，尤其是当您与高级开发人员交谈时，他们似乎对所有事情都一窍不通。 但是问问自己：这个人正在解决他们已经知道答案的问题吗？ 他们会成功地进入一个崭新的领域吗？

您年纪越大，通常就很少涉及背景，您就越应该承担复杂，定义不明确的问题。 增强影响力的真正秘诀是学习如何解决任何规模的问题并将其分解为可以成功解决的可管理部分。

我已经雇用，指导和晋升了数十名实习生和应届毕业生，并且亲眼目睹了开发一种对您有用的解决问题的方法可以引导您走上最快的成功之路。

编程是一项团队运动

看看你周围。 有经验的开发人员正在合作吗？ 在我的整个职业生涯中，我曾在IBM，Blackberry，Shopify和Lever等公司工作。 我观察并练习了许多方法来集思广益和验证想法。 这些范围从合作团队活动，如结对编程，白板，轻松的头脑风暴，对问题和拉动请求的评论（PR）-到更正式的“大公司”流程，例如技术设计审查和体系结构审查委员会。

尽早获得反馈

在大多数公司中，您要求在运输之前对实施进行审查。 新开发人员经常会误解此步骤的重要性。 他们认为目标是独立工作，直到问题完全解决为止，然后在代码检查时公开该问题以供反馈。 这是一个巨大的错误！

大多数经验丰富的开发人员不会等到他们实施解决方案来集思广益并与他人验证这个想法 。 从一开始，它们就是透明和协作的。

他们已经了解了解决问题的能力的秘密：尽早寻求反馈，通常会导致更多高质量的想法和更好的解决方案。

作为一个经验丰富的开发人员，与审查采用完全错误的方法的PR相比，我感到最满意的是-告诉别人重写他们编写的大部分代码，这没什么好玩的。 如果您提前让我参与进来，我可以帮助您解决问题，或者就所编写的一些代码给您反馈，以免您在整个过程中都不会犯错。 我们还可以进行面对面的对话，以便您真正理解我的反馈，而不是尝试解释书面评论。

预先确定合作伙伴

从一开始就选择团队中的开发人员进行工作。 理想情况下，您已经有一个正式的导师或伙伴-与您交往的人关心您的成功并会帮助您学习。 如果您没有，找到一个！ 如果不是您的正式好友，或者您没有正式好友，请主动询问他们是否有时间，并确保他们致力于您的成功。 最后应该是将执行代码审查的人员。 此人将挑战您对问题的理解，帮助您解决问题，并最终检查您的代码。

理想情况下，它也应该是在您正在工作的领域中具有足够背景知识的人，以便他们可以回答有关预期如何工作的问题。 他们不需要成为专家。 实际上，我经常发现，在开发方面仅领先于您的开发人员提供了最佳的指导，因为他们最近才学到了您需要了解的知识，并且经常为应用这种学习感到兴奋。 他们还可以从指导中受益最大，因为它可以帮助他们巩固已经学到的知识。

进步！=编写代码

有许多方法可以使问题取得进展，而它们并不都涉及编写代码。 经验丰富的开发人员从整体上看待进度，使自己能够突出他们在理解问题上所取得的进步并与他人一起验证自己的想法。

使用新方法突出您的进度

在验证对问题和方法的理解时，无论是使用Jira，Github还是其他工具，我都会经常在问题本身上发表评论，无论使用的是哪种问题管理工具。 当我处理一个更复杂的问题时，我将使用文档， 要旨或新问题来捕获设计，然后收集反馈。 我喜欢这些选项，因为它们使协作和评论变得容易。

考虑一下您公司使用的工具，并在开发人员花费时间的情况下发布进度。 开发人员最常使用哪些工具？ 如何使用它们？ 您交流和验证自己的进度最透明的方法是什么？ 您团队中谁拥有最详细的问题和PR说明，设计文档以及PR评论？ 有没有可以模仿的方法？ 确定最好的工具，以捕获每一步的进度。

记录=交流=合作

这是一个秘密： 所有开发人员都可以站起来记录他们的进度。

这感觉违反直觉：好像您年纪越大，就越无需在问题中进行自我解释和审查请求。 但我希望有更多的高级开发人员。 您越有经验，我就越希望您清楚地记录您的分析和方法。 作为高级工程师，您不仅在向代码审阅者解释自己，而且还在为团队中的其他所有人建模。

这带来了两个明显的好处。 首先，您可能会以不同于其他所有人的独特方式来解决问题，并且我们希望鼓励采取多种方法，以尽可能成为最佳的工程团队。 其次，您将分享如何解决问题的知识和经验，对特定问题领域的了解以及软件工程原理和模式在解决问题中的应用。

尽早验证

我向所有抱怨后期的代码审查反馈导致重写他们刚刚实现的大部分内容的开发人员解释了这一点。 在将PR进行审核之前，您是否可以预先捕获其他方法以获得反馈？ 您能否为某些东西制作原型并对其进行配对编程，以获取您可能缺少的任何背景信息？

“提早进行五分钟的对话可以节省您以后重写的时间。”
— DJ霍顿

您可能要比其他人做更多的记录，但是我从未听说有人对某人的记录过多给予负面反馈。 很多时候，我的团队成员因他们所做的彻底调查工作以及与他们合作的无缝性而受到赞扬。 正是这种周到的方法为队友之间的协作提供了最佳的机制。

了解问题

您已分配任务-太好了！ 第一步是了解问题。 有多种解决方法吗？ 通常，在您职业生涯的这个阶段，任务会告诉您确切的预期结果。 也许它甚至包括屏幕截图。 但是，没人知道您在开始使用解决方案时会发现什么，因此不要指望它可以完全按照要求的方式工作。

为什么先

无论任务是编写新方法还是创建新的面向用户的功能，了解功能存在的原因以及解决的问题对您的成功至关重要。

假设您正在开发面向用户的组件，并且要求您在用户界面中公开一个新字段。 该字段已经存在于后端，可以通过API进行设置，因此您只需要创建一个位置即可在用户界面中显示它。 有一个截图-易于复制，对吧？

但是，为什么该领域对用户很重要？ 它总是存在还是在某些情况下不存在？ 它有最大尺寸吗？ 是否需要输入验证？

这是一个很好的机会，可以了解产品的新领域并集思广益，可能需要测试一些前沿案例。 不要以为每个案例都引起问题的产生。 他们可能只包括了他们所知道或记住的内容。 如果问题是由外部利益相关者（例如支持）创建的，则尤其如此。

但是，您现在就在解决这个问题，并且在发货之前，您将在用户体验方面成为专家。 考虑一下其中的力量：通过深刻理解问题并尽早进行协作并经常解决这些问题，可以使您的产品和公司变得更好。 经验丰富的开发人员可以帮助您创造出令人赞叹的产品。

设置环境

此时，我还建议您开始设置本地环境以手动测试该区域。 这可能意味着要学习单击以进入要编辑的视图。 这也可能意味着创建一些新数据，这些数据将开始创建您要测试的某些排列。 您最终将需要这样做，并且现在做的越多，您越有可能完全理解问题并且不会遇到任何意外。

验证你的想法

到此步骤结束时，我希望您已经与您的导师交谈，以验证您对产品在实施完后应如何工作的理解。 我也希望您在问题管理系统中编辑描述或对原始任务添加评论。 即使实际上是相同的，该评论也应该：

• 描述您的理解
• 确定唯一的排列或限制，
• 包括解决问题的计划和预期的用户体验

出于许多原因，此书面步骤很重要。 首先，它开始培养您对理解和掌握问题的信心。 其次，它使您的导师可以确保您理解讨论问题时交换的任何反馈。 第三，您是一个更大的团队的一部分！ 有了本文记录，其他人可以查看您的方法，而其他利益相关者（例如设计师和产品经理）可以查看您的进度并提供反馈。

也许最重要的是，您已经取得了明显的进步（不仅仅是编写代码！）。 值得庆祝的东西！ 🎉

确定方法

一旦了解了问题，就该提出解决方案了。 考虑创建一个用于原型的临时分支。 并非您编写的所有代码都值得发布。 这是使用本地环境进行更改以查看有效方法的好时机。 您可能需要更改或创建哪些文件和方法？ 借此机会，您可以尝试并做出您从未考虑合并的更改。

产生替代方案

即使有一个明显的赢家，通常也有不止一个解决方案。 我建议花一些时间考虑至少两种方法。 我们通常首先实施最简单，最直接的方法。 但这可能不是最容易维护或性能最高的。

一旦有了至少两种方法，请记录每种方法的利弊。 您可以在任何地方的临时文件中进行操作。 对最佳解决方案提出意见。 您希望实施和支持哪个？ 提出意见后，请与您的导师或伙伴讨论这些方法。 您错过了任何利弊吗？ 您是否成功确定了最佳的前进方向？

“对我而言，了解自己有能力/有能力形成意见并主张我认为哪种方法最好是很有意义的！ 以前，我会提出一些方法，但是要等我的导师告诉我要走哪条路。 我必须意识到，即使最终没有成为建议，也可以形成意见提出建议。 那是学习！” —黄燕妮

最近，我向刚开始与我合作的人建议了这种方法。 第二天，她与技术主管安排了每周的配对编程会议。 她准备了方法，利弊的清单以及可供选择的观点。 后来，技术负责人让我知道这是他们参加过的生产力最高的结对编程会议。 当我要求我的新报告对此进行反思时，她有这样的话：“总是被告知要为结对编程会议做准备，但没人能解释所准备的内容。”

这并不是说您应该为所有结对编程会议做准备，因为您将处于解决问题的不同阶段。 但是，如果您只是开始着手解决新问题，那么这是一项很棒的技术，可以帮助您证明已经投入了多少想法，并验证了发现的内容。

分解

现在您知道如何实施该解决方案，请考虑该解决方案的组件。 您需要编写多篇文章吗？ 其中一些甚至可以作为自己的PR独立运送吗？ 确保与导师一起验证如何计划分解实施。 他们也许能够帮助您识别出您没有想到的其他组件或依赖项。

保持小

将问题分解为您可以想到的最小组件。 每个组件越小，越容易理解，开发和测试。 而且，小的代码更改更简单，并且花费的时间更少。 进行较大的更改后，审阅者可能会觉得他们需要花些时间才能获得适当的顶空。 进行较小的更改，他们就可以快速跳入而不会丢失他们的流程。 您将更快获得反馈-赢了！ 您不仅可以更快地移动，而且在成功发货之前也将得到较少的反馈。

保持可测试性

如果您决定单独运送PR，请记住，这些PR应该仍然是完整的。 例如，您可以引入一个新的后端方法，该用户界面最终将在另一个PR中使用该方法。 该方法必须独立工作，因此非常适合进行分离。 自动化测试应同时交付。

进一步分解

最后，请记住编程是迭代的。 在开始实施解决方案时，您可能会了解到可以细分一些部分。 您是否应该将其分解成更小的部分？ 最近，我团队的一名开发人员发现，她要编写的自动化测试需要重构先前存在的代码才能进行测试。 由于她的PR已经具有测试范围并且已经过全面审查，因此她选择独立实施重构和自动测试。 由于将该重构分为自己的更改，因此她能够避免重新访问已实现的代码。 她还减少了队友花在审阅同一代码上的时间。 最后，她能够更快，更自信地交付重构和新测试。

合计：成功工程师的工作流程

请记住，增加影响力的真正秘诀是学习如何解决各种规模的问题并将其分解为可以成功解决的可管理部分。 您将如何开始解决更大的问题？

无论您是刚刚开始从事软件开发人员的职业，还是经验丰富，正在寻找与团队和其他人更好地协作的方法，我希望您都花些时间考虑一下如何为您提供帮助。 您理想的心理模式是什么？ 您如何改善有关问题解决方案的沟通和征求反馈？ 具有适应能力，并考虑如何与团队的现有工具和流程一起最佳地成功应用该方法。 您使用什么方法？ 在评论中让我知道！

From: https://hackernoon.com/a-problem-solving-workflow-for-junior-software-developers-h4u30ej