这是我给许多新手开发人员的建议，并且我希望能够在刚入门时就给自己（尽管其中一些建议指的是那时不存在的资源）。 如果您觉得它有用，请考虑与您认识的人分享，也可能会从中受益。
路障
作为程序员或软件开发人员，您可能会不时地尝试解决问题，而事情只会走不通。 您正在区域中，正在编写代码，完成工作并感觉良好。 然后某事不起作用。 “没问题，”您自己想，“我会尝试这种略有不同的方法……”而且那也不起作用。 或接下来的事情。 还是下一个。 很快，您可能会发现自己变得沮丧。 对于程序员来说这是很常见的现象，它具有自己的流行模因：
振作起来：每位程序员都会遇到难以诊断的阻塞性问题（如果从未发生过，请发表评论）。 希望这一事实将帮助您在考虑要做什么时避免某些自然冒名顶替综合症（如果您想知道编程是否真的想做的话，可能会有所帮助）。 当您陷入困境时，在转动车轮时，可以采取以下措施来帮助您尽快回到正轨。 请记住，程序员的时间往往很昂贵，而时间是您拥有的最宝贵的资产。 不要浪费它，或者浪费您的公司或客户的钱！ 尽快回到生产状态（和更快乐！）。
面包屑（或线程）
Hansel和Gretel的故事描述了两个孩子如何因为丢下一条面包屑而在树林中迷路，但是这条路被鸟吃掉了，所以他们找不到回家的路。 遗憾的是，尽管这个故事表明面包屑是找到返回安全位置的糟糕方法，但该术语仍被用来精确描述此功能。 更好的文学类比是Ariadne的Thread ，但这鲜为人知。 无论如何，当您发现自己遇到问题时，您应该考虑的第一件事就是确保您有返回“已知良好状态”（KGS）的方法。 显然，最好的方法是使用源代码控制。 理想情况下，您最后一次在KGS中发现自己（至少在本地）。 如果您遵循的是TDD，请尝试同时遵循Red-Green-Refactor-Commit（甚至RGCRC） 。 即使您不编写测试，也请经常检查 。 这样可以救你。 养成习惯。 如果卡住了，在开始撕裂正在处理的所有东西或将东西扔在墙上以查看哪些东西卡住之前，请确保您有正在工作的代码副本（如果可以的话，则几乎可以正常工作）已航行）状态。 至少（如果您仍然不相信现在使用源代码控制），请应用“ 复制文件夹版本控制”反模式 ，并使自己成为正在使用的文件夹的备份副本（或ZIP）。
定时装箱
要牢记的下一项技术称为时间盒 。 如果您不熟悉此术语，它只是指预先设置最大时间以用于特定活动的想法。 在对问题进行故障排除的情况下，最多可以给自己分配10或15分钟的时间来解决问题。 设置一个计时器，并坚持下去。 如果您有时间解决问题，那就太好了！ 拍一下自己的背，给自己零食以奖励，做任何事情来帮助自己回到该地区，然后重新开始工作（不要忘记办理登机手续）。 如果您的计时器关闭，但您仍然陷于困境，请继续使用以下一种技术。
寻找答案
很难想象，但是有一段时间人们不得不编写软件而无法访问Google或Stack Overflow，甚至无法访问即时通讯程序和Slack（或IRC）。 幸运的是，现在还不是时候。 您生活在21世纪。 您触手可及的地方就可以获取世界知识的总和。 如果您被困了超过几分钟，则应该停止旋转轮子或将头撞在墙上或任何似乎最合适的比喻，然后开始使用已有的线索寻找答案。
从谷歌搜索开始（或者您可以用必应搜索Google）错误消息。 这也有一个原因激发了幽默的模因和书籍封面，这是有原因的-它在很多时候都起作用。
添加一些与您使用的技术堆栈相关的关键字。 您会惊奇地发现，有一定经验的人能很快找到答案（注意： 这些不是他们自己知道的答案 ）。 这是您应该开发的一项技能，并且要改进它的一种不错的方法。 您已经陷入困境，您已经为几分钟提供了最佳射击，看到其他人之前是否曾遇到过这个问题并从他们的经验中学到东西也没有什么可耻的。
当然，寻找答案的回报也越来越少。 你应该时间盒故障排除的这个阶段也是如此。 我建议将其限制为另外10或15分钟。 请记住，只有一个人，并且一次只能采用一种方法来解决问题。 如果您已经花费了30分钟，现在完全被阻止了，而您仍然无法弄清为什么事情不起作用，那么该是时候寻求帮助了。
借鉴他人的经验
如果您还没有这样做，请专门针对您的问题搜索StackOverflow（或相应的Stack Exchange网站）（而不是依赖Google从该网站获取答案）。 假设这不能解决问题，请花一点时间自己为StackOverflow（SO）提出一个问题。 在花一些时间自己解决问题之前，不要跳到这一步。 通过演示您所付出的努力来表达对他人的尊重，比起每隔5分钟寻求帮助的情况，您更有可能获得良好的答复，并且您自己显然并没有付出太大的努力。
将问题发布到SO后， 世界其他地方现在将在您自己的努力下帮助您解决问题！ 这是巨大的，但是如果有必要，您可以通过各种方式寻求问题的答案，从而进一步帮助您（再次不要过于频繁地这样做，否则您会耗尽他人对您的善意）。 发布您的问题的简要概述以及解决该问题所采取的步骤，并使用您属于其中并且似乎合适的任何以下社区来链接至SO问题：
- 同事和内部帮助邮件列表
- 松弛-公共社区或公司的私人松弛
- Twitter-使用适当的哈希标签
- 其他在线社区和邮件列表
很多时候，您甚至都不会发布问题，因为仅提出问题通常可以帮助您解决问题。 这称为橡皮鸭调试 。
在问您的同事之前，先尝试向橡皮鸭解释您的问题，大部分时间问问题（大声地，理想地）会帮助您确定答案。
休息一下
如果已完成上述所有操作，但仍未找到答案，请休息一下。 根据情况的不同，这可能意味着要上床睡觉，午餐，吃点点心，甚至只是查看电子邮件或进行其他工作。 不过，在这一点上，世界其他地方正在帮助您解决此问题，因此即使您稍事休息，您仍然（可能）更接近答案。 而且您的潜意识也仍然很强。 当您回到问题上时，您可能会注意到之前被忽略或视为理所当然的事情，它可以解决整个问题（或者可以帮助您意识到自己实际上在解决错误的问题，这种情况也经常发生）。
应用科学方法
当您被阻止并且不确定根本原因是什么之后，花一小段时间只是尝试尝试一些事情，看看有什么用，这有助于重新组合并变得更有条理。 将科学方法应用于您解决问题的方法。 对可能的根本原因进行理论分析。 确定一种方法来证明（或反证！）您的理论是正确的。 这是一个实验。 运行实验并捕获结果。 希望结果可以帮助您确定理论是否解释了您所看到的行为。 如果不是，请通过重复操作继续减少问题的可能根源。 在执行此过程时，请确保一次只更改一项。 这是另一个时候，良好的源代码控制确实可以为您提供帮助。 如果可能的话，也可以考虑将您正在进行的某些实验自动化。 编写一些断言您的应用程序的一部分在某些条件下以某种方式运行的代码-在我看来，这听起来像是单元测试或集成测试。 如果您认为将来能够运行相同的测试（也许通过每次生成源代码控件时都通过构建服务器）可能很有价值，请考虑将您的实验编码为测试。 或者更好的是，首先编写尽可能多的实验作为测试，这导致我们……
使用自动化
使用测试，构建脚本，构建服务器和其他自动化技术，可以最大程度地加快解决问题时的诊断速度，并确保“修复”没有引入新的问题。 自动化测试的价值不是在告诉您编写代码时的行为，而是在告诉您代码在将来的某个时刻仍会以这种方式运行。 更有价值的是，当测试能够告诉您您的代码不再执行您刚刚引入的更改（您甚至不知道会影响测试所覆盖的代码）后所做的工作时，它就变得更有价值。 如果您在测试中获得的唯一价值在于验证您的代码是否达到了您目前认为的功能，那么您就失去了进行此类测试的大部分时间。 当您发现自己被阻止时，测试可以为您显示所有未损坏的内容提供很大的帮助。 并且，如果其中任何一个损坏，它们可能会通过向您显示问题的根源来帮助您畅通无阻。
摘要
你会被卡住的。 这很令人沮丧，但每个人都会发生。 确保以一种积极的方式对待它，并采用能够最大程度减少卡住时间的策略。 作为开发人员，我们一直在尝试在最多两年前甚至不存在的软件之上构建从未有过的东西。 它任何一个都能正常工作的事实令人惊讶。 您认为应该是相对简单明了的任务这一事实有时会导致花费大量时间来尝试弄清IT的原因。 只是。 不会。 工作。 只是这部分工作的一部分。 这不是你的错，也不只是你。 通过应用上述想法，最大程度地减少您允许自己花费多少时间尝试畅通无阻，如果您有任何自己的想法可以分享，请在下面的评论中发布。
最初在 ardalis.com上 发布 。 如果您觉得这有用，请留下掌声并考虑加入我的 每周开发技巧时事通讯 或 podcast 。
From: https://hackernoon.com/working-through-roadblocks-a-guide-for-new-programmers-826c2aa455a2