成为经验丰富的软件开发人员，并不意味着需要知道每个问题的解决方案，也不意味着要了解整个系统及其细枝末节。
我明白了。感觉上你应该很了解这些东西，尤其是当你和一个高级开发人员交谈时，他似乎知道所有的事情。但是问问自己:这个人是在解决一个他们已经知道答案的问题吗?他们也会同样进入一个全新的领域吗？
你的职位越高，就越有可能被要求处理一些复杂的、定义不清的问题，而且这些问题通常没有什么背景信息。提高影响力的真正秘诀是学习如何处理任何规模的问题，并将其分解成可以成功解决的小问题。
我已经雇佣、指导、提拔了几十名实习生和应届毕业生，我也总结了一种适合自己的解决问题的方法，希望可以引导你们走向成功的捷径。
目录
编程是一项团队活动
看看你周围。经验丰富的开发人员是否合作？在我的整个职业生涯中，我曾在IBM，Blackberry（黑莓），Shopify以及现在的Lever等公司工作过 。我观察和实践了许多方法来进行头脑风暴和验证想法。这些活动包括协作的团队活动，如结对编程、白板、轻松的头脑风暴、对问题的评论和pull request(PR s)，以及更正式的大公司流程，如技术设计评审和架构评审委员会。
尽早获得反馈
在大多数公司中，您在发布之前会要求对实现进行审查。新开发人员常常误解这一步的重要性。他们假设目标是独立工作，直到问题完全解决，然后在代码评审时公开反馈。这是一个巨大的错误。
大多数有经验的开发人员不会等到他们实现了解决方案后才进行头脑风暴并与他人验证这个想法。他们从一开始就是透明和协作的。
他们已经学会了解决重大问题的一个小秘密:尽早寻求反馈，通常会带来更多高质量的想法和更好的解决方案。
作为一名有经验的开发人员，没有什么比审查一份采用了完全错误的方法的PR更让我感到糟糕的了。如果你一开始就和我合作，我可以帮你解决问题，或者对你写的一些代码给你反馈，这样你就不会一直重复错误。我们也可以进行面对面的交流，这样你才能真正理解我的反馈，而不是试图去解释书面的评论。
提前确定合作伙伴
从一开始就在您的团队中选择一个可以一起工作的开发人员。理想情况下，你已经有了一个官方的导师或伙伴，他们会关心你的成功并帮助你学习。如果你没有，那就找一个!如果他不是你的正式伙伴，或者你没有，主动询问他们是否有时间，确保他们对你的成功负责。应该是在最后执行代码检查的人。这个人会挑战你对问题的理解，帮助你解决问题，并最后检查你的代码。
理想情况下，还应该是在你工作的领域有足够背景的人，这样他们就可以回答关于某事应该如何工作的问题。他们不需要成为专家。事实上，我经常发现在开发方面比您领先一步的开发人员提供了最好的指导，因为他们最近才了解您需要了解的内容，并且常常很乐意应用这些知识。他们也能从辅导中获得最大的收获，因为辅导能帮助他们巩固他们已经学过的东西。
进步！=编写代码
在一个问题上取得进展的方法有很多，它们并不都涉及编写代码。有经验的开发人员对进展有更全面的看法，能够突出自己在理解问题方面取得的进展，并与他人一起验证自己的想法。
用新方法突出你的进步
在验证我对问题和方法的理解时，我通常会在我们使用的任何问题管理工具(无论是Jira、Github还是其他工具)中对问题本身进行评论。当我处理更复杂的问题时，我会使用文档、摘要或新问题来捕获设计，然后收集反馈。我喜欢这些选项，因为它们便于协作和评论。
考虑一下您的公司使用的工具，并将您的进展发布到开发人员常去的地方。开发人员最常使用什么工具?它们是如何被使用的?对你来说，最透明的沟通和确认自己进步的方式是什么?您的团队中谁拥有最详细的问题和需求描述、设计文档和评论?有什么方法可以模仿吗?确定最好的工具来捕获每一步的进展。
记录=交流=协作
这里有一个秘密:所有的开发人员都可以记录他们的进展。
这让人感觉与直觉相反:似乎你的职位越高，你就越不需要在自己的问题和审核请求中做出解释。但我希望有更多的高级开发人员，你的经验越丰富，我就越希望你能清楚地记录下你的分析和方法。作为一名高级工程师，你不仅要向你的代码评审员解释你自己的想法，还要为团队中的其他人复述你的想法。
这带来了两个明显的好处。首先，您可能会以不同于其他任何人的独特方式解决问题，我们希望鼓励各种方法尽可能成为最好的工程团队。其次，您正在分享您在如何处理问题方面的学习和经验，您对特定问题领域的知识，以及您对软件工程原则和模式的应用来解决问题。
尽早并经常验证
我向任何开发人员解释了这一点，当延迟的代码评审反馈导致他们刚刚实现的大部分代码被重写时，他们会抱怨。在将PR提交审查之前，你是否已经预先捕获了不同的方法以获得反馈?你是否可以在很早的时候就制作出原型并对其进行配对编程，以获得任何你可能错过的信息？
“提前五分钟的谈话可以为你节省几个小时的重写时间。”
— DJ Houghton
你可能会比别人更多地记录，但我从来没有听说过有人因为记录太多而给别人负面的反馈。我的团队成员曾多次因为他们所做的彻底的调查工作以及与他们合作是多么的天衣无缝而受到赞扬。正是这种深思熟虑的方法为团队成员之间的协作提供了最好的机制。
你被分配了一项伟大的任务!第一步是理解问题。解决这个问题的方法不止一种吗?通常，在你职业生涯的这个阶段，任务会确切地告诉你预期的结果是什么。也许它甚至会包括截图。然而，没有人知道当您开始处理一个解决方案时将会发现什么，所以不要期望它完全按照要求的方式工作。
为什么在这之前？
无论任务是编写一个新方法还是创建一个面向用户的新特性，理解该特性为什么存在以及它解决了什么问题对您的成功都是至关重要的。
假设您正在处理一个面向用户的组件，并被要求在用户界面中公开一个新字段。该字段已经存在于后端，可以通过API进行设置，因此您只需创建一个位置来在用户界面中显示它。这是一个很容易复制的截图，对吗？
但是为什么这个字段对用户很重要呢?它总是存在还是在某些情况下不存在?它有最大限制吗?是否需要输入验证？
这是一个很好的机会来了解产品的一个新领域，并对您可能需要测试的一些边缘案例进行头脑风暴。不要假设提出问题的人考虑了所有的情况。他们可能只包括他们知道或记得的。如果问题是由外部人员(例如技术支持)创建的，那么这一点尤其正确。
但是你现在正在解决这个问题，当你发布的时候，你将成为用户体验方面的专家。想想这其中的力量:通过深入地理解问题，及早并经常地协作来解决问题，您正在使您的产品和公司变得更好。有经验的开发人员帮助创建令人惊叹的产品。
设置环境
此时，我还建议开始设置本地环境来手动测试此字段。这可能意味着要学习点击进入你正在编辑的视图。这也意味着创建一些新的数据，这些数据将开始创建您想要测试的一些排列。您最终需要这样做，并且您现在做得越多，就越有可能完全理解问题并避免出现任何意外。
验证你的想法
在这一步结束时，我希望您已经与您的技术主管进行了交谈，以验证您对产品在完成实现后应该如何工作的理解。我还希望您在问题管理系统中编辑描述或对原始任务添加注释。即使它们实际上是一样的，那个评论也应该是一样的。
- 描述你的理解
- 确定独特的排列或限制
- 包括你的解决方案和预期的用户体验
这个写下来的步骤很重要，原因有很多。首先，它开始培养你对理解和掌握问题的信心。其次，它可以让你的导师确保你理解在讨论问题时交换的任何反馈。第三，你是一个更大的团队的一部分!有了这些文档，其他人就可以检查您的方法，而其他人员(如设计人员和产品经理)可以看到您所取得的进展并提供反馈。
也许最重要的是，您已经取得了明显的进展(这不仅仅是编写代码!)，真是值得庆祝的事情！
确定你的方法
一旦你理解了这个问题，就该拿出解决方案了。考虑为原型创建一个临时分支。并不是所有你写的代码都值得发布。这是使用本地环境进行更改以查看哪些操作有效的好时机。您需要更改或创建哪些文件和方法?把这看作是你的机会，你可以尝试做一些你从未考虑过合并的改变。
产生替代方案
通常存在不止一个解决方案，即使其中一个明显是最好的。我建议至少花点时间考虑两种方法。我们通常首先实现最简单、最直接的方法。但它可能不是最容易维护或最有效的。
一旦你有了至少两种方法，记录下每种方法的优缺点。您可以在gist中执行此操作，也可以在任何地方的临时文件中执行。对最佳解决方案提出意见。您希望实现和支持哪一个?一旦你有了一个想法，通过这些方法和你的技术主管或伙伴交谈。你有没有错过什么优点或缺点?你是否成功地确定了前进的最佳路径。
“这对我来说很有意义，因为我有能力形成自己的观点，并且支持我认为最好的方法。而以前，我会想出一些方法，但要等我的导师告诉我该走哪条路。我必须意识到，形成一个观点来提出一个建议是可以的，即使它最终没有被选中。这才是学习！”
— Stephanie Wong
最近，我向一个刚开始和我一起工作的人建议了这种方法。第二天，她和她的技术主管安排了一个每周一次的结对编程会议。她准备了她的方法清单，赞成和反对，并选择一个意见。后来，技术主管告诉我，这是他们举办过的最有成效的结对编程会议。当我要求我的新报告对此进行反思时，她是这么说的:我一直被告知要为结对编程课程做准备，但从来没有人解释过准备是什么样子的。
这并不是说你应该这样准备所有的结对编程课程，因为你将处于解决问题的不同阶段。但如果你刚刚开始解决一个新问题，这是一个很好的技巧，它可以帮助你证明你已经投入了多少思考，并验证你的发现。
分解
现在您已经知道了如何实现解决方案，接下来考虑该解决方案的组件。你需要写很多篇文章吗?其中一些甚至可以作为它们自己的PRs独立运行吗?确保与您的技术主管确认您计划如何分解实现。可以帮助您识别您没有想到的其他组件或依赖项。
Keep it small（尽量小）
把问题分解成你能想到的最小的组成部分。每个组件越小，就越容易理解、开发和测试。更重要的是，小的代码更改更简单，花更少的时间来检查。对于较大的更改，评审员可能会觉得他们需要留出时间来获得正确的修改。通过一些小的改变，他们可能能够快速地跳入而不会失去他们的流程。你会更快地得到反馈!这样你不仅可以更快地前进，而且在你成功发布之前，你需要处理的反馈也会更少。
Keep it testable （可测试）
如果你决定单独发布的PRs，记住这些仍然应该是完整的。例如，您可以引入一个新的后端方法，用户界面最终将在另一个PR中使用它。自动化测试应该同时交付。
Break it down further （进一步分解）
最后，请记住编程是迭代的。当您开始实现您的解决方案时，您可能会了解到有些部分可以进一步分解。你应该把它拆成更小的块吗?最近，我的团队中的一个开发人员发现，她想要编写的自动化测试需要对先前存在的代码进行重构才能进行测试。由于她的PR已经有了测试覆盖，并且已经被完全审查过，所以她选择独立地实现重构和自动化测试。由于将重构分解为自身的更改，她能够避免重新访问已经实现的代码。她还减少了她的队友需要花费在评审相同代码上的时间。最后，她能够更快地发布重构和新的测试，并且有更高的信心。
合并：成功工程师的工作流程
记住，提高影响力的真正秘诀是学习如何处理任何规模的问题，并将其分解成可以成功解决的小问题。你将如何着手解决更大的问题
无论你是作为软件开发人员开始你的职业生涯，还是你很有经验，正在寻找更好地与你的团队和其他人合作的方法，我希望你会花一些时间来考虑这将如何帮助你。你理想的心智模式是什么?你如何改进沟通和征求对你的问题解决方案的反馈?要适应力强，并考虑如何通过团队现有的工具和流程成功地应用该方法。你使用什么方法?请在评论中告诉我
译自： https://hackernoon.com/a-problem-solving-workflow-for-junior-software-developers-h4u30ej