如何通过提问成为更好的开发人员

Posted 2021-09-09 dotNET跨平台

如何通过提问成为更好的开发人员

这是新的一年的开始，所以我想以一篇我已经计划写了一段时间但从未真正开始创作的帖子开始。我最近开始了一份新工作，加入Elastic^[1]，负责开发他们的 .NET 语言客户端。因此，最终将这个主题编写并发表是合适的。结果证明这是我较长的帖子之一，因为我有很多话想说。我建议拿起一杯茶或咖啡，坐下来阅读这篇文章！

提出问题是一种积极的行动

在我作为软件工程师的这些年里，我问了很多问题。开发人员也向我提出了他们自己的问题。有时，这些对话的开头是“抱歉，在这么简单的事情上浪费了你的时间……”。在这篇文章中，我想阐明为什么没有开发人员，无论是新的还是有经验的，都应该道歉或回避提问。它们是构建您自己的体验并成为更好的开发人员的关键部分。

有几乎无限量的知识需要学习。没有一个人可以知道一切。在软件开发方面，我们的行业发展非常迅速。最新的新技术很快就会被其他东西所取代。曾经首选的架构风格已经过时或被高级模式所取代。在这方面，所有软件开发人员都面临着试图跟上步伐的相同挑战。老实说，要真正跟上一切是不可能的。

当然，一种解决方案是找到单一的技术和编码模式，然后坚持使用。这在变革步伐通常较慢的大型企业中并不少见。尽管如此，相信企业中的每个人都可以了解有关其现有开发环境的一切是不切实际的。它也不能避免相关技术和工具的变化。也许您使用了源代码控制产品或规划工具，它们会随着时间的推移而发展，从而迫使您进行一定程度的学习和适应。出于安全考虑，曾经首选的 API 可能会被弃用，迫使开发人员理解和使用更安全的替代方案。

软件开发是一门手艺，就像任何手艺一样，在此过程中需要做出个人风格和选择。怀疑您编写的代码是否是解决问题的“最佳”方式以及您想征求他人意见的想法是完全合理的。

也许您是在即将开始您的第一份软件开发工作时阅读本文的。如果是这样，恭喜！或者也许你在去年开始了一份新工作。我的主要建议是不要害怕提问，不要觉得这会让你成为一个更糟糕的开发人员。我很乐意争辩说，我认为有疑问的人在某些方面是更好的开发人员。它表明您对自己的工作感兴趣，愿意学习并热衷于改进。没有什么不妥！

对于更有经验的开发人员；从那些有几年在职经验的人到那些已经编码了几十年的人，你应该仍然有问题。我观察到长期开发人员害怕提问的情况，甚至可能比初级开发人员更害怕。可能有很多因素在起作用，但在某种程度上，我怀疑这是某种程度的冒名顶替综合症。更高级的开发人员可能不希望在软件开发的某些方面显得天真。也许他们认为他们应该知道一些事情，并且害怕透露他们不知道。这可能非常危险，因为那些开发人员可能更愿意猜测，而不是真正了解选择是好是坏。对于阅读这篇文章的高级开发人员，我现在问你，你还记得你上次在工作中问技术问题是什么时候吗？你上周提出了多少问题？如果您很难回答这些问题，那么您可能下意识地避免提问。

高级开发人员也会换工作，虽然您可能担任高级职位，但可以合理地假设您在为新雇主工作的最初几周和几个月内会遇到很多问题。您可能不确定为什么要使用特定方法、首选特定模式或特定代码段的作用。在这种情况下，询问应该没有什么问题。如果雇主和经理对这些问题不以为然，那么他们可能不是最好的雇主。假设所有新的高级员工都会在第一天就知道一切，这是不合理和不切实际的。

作为开发人员，您的问题不必局限于纯粹与代码相关的主题。您可能想知道为什么要使用特定的计划流程，如何平衡您的时间或如何提交费用报销。这些也是提出问题的完全合理的话题。

如果你已经读到这里，你现在应该已经学会了，我想鼓励大家提出问题。因为正是提出问题的行为推动了我们的知识进步。

准备提问

必须首先说明并非所有问题都必须亲自提出。对于大多数问题，我建议您首先尝试自己回答问题。我的意思是，在线、在公司 wiki 或参考材料和文档中研究问题。您很少会是第一个提出特定问题的人，因此获得答案的最快方法通常是先向 Google 或 Bing 寻求答案。谷歌搜索还在问一个问题！

如果您的问题是关于您试图理解的某些代码，请给自己时间正确阅读（并重新阅读）代码。此外，请确保您查看所有测试。某些代码可能非常复杂，尤其是在大型遗留代码库中。虽然代码本身可能难以解释，但测试（如果存在）可以帮助您了解它的意图。阅读和解释代码是软件开发人员掌握的一项基本技能，我之前曾在博客中介绍过^[2]。任何实践这一点的机会都应该被拥抱。如果您在尝试自己收集代码的作用后仍然需要寻求他人的帮助，那也没关系，但请先从那里开始。

如果您的问题是关于为什么您编写的某些代码失败或导致异常，请在与其他人接触之前花一点时间尝试隔离和理解问题。检查您的代码是否有可能是原因的错误。您是否编写了任何测试，这是否有助于证明代码的哪一部分是罪魁祸首？您是否已调试应用程序以追踪出现问题的地方？您是否尝试在较小的样本中重现错误？这些技术是一个很好的练习。同样，这里的想法不是避免提出问题，只是为了确保您的问题无法在您自己的脑海中得到解答。随着你职业生涯的进步，你可能会解决越来越多的自己的障碍，但他们需要寻求帮助永远不会完全消失。

在 GITHUB 和 STACK OVERFLOW 上提问

另外，请考虑一些问题也可能更适合在线论坛和资源，例如Stack Overflow^[3]或GitHub^[4]。有些问题是针对一段失败的代码，询问关于可接受的模式使用或使用开源库的方法的意见。对于这些，您可能会发现更广泛的在线开发人员社区可以更好地为您提供帮助。

在线提问可能非常令人生畏，甚至比与您认识的人联系更令人生畏。它的优势之一是您可以接受更广泛、更多样化的意见和想法。您需要进行更多过滤和个人判断，以验证答案是否合理。如果在收到一些答案后，您仍然不确定它们，您可以随时询问您信任的人进行最终验证。

在线论坛支持培养良好的提问行为。例如，假设您正在打开 GitHub 问题或开始讨论开源项目的正确用法。在这种情况下，您应该尝试查找之前是否已被询问和回答。当一个简单的搜索就可以产生您需要的答案时，维护人员可能会感到沮丧。不检查会让维护者觉得你比他们自己的时间更有价值。

你还应该确保你遵循我上面的建议。如果您认为自己发现了错误或正在为库的使用而苦苦挣扎，请演示并分享合理的最小复制，而不是期望其他人阅读额外的代码或尝试自己复制它。确保您已尝试先调试代码并阅读文档。如果您在自己做出合理的努力来回答问题后遇到困难，请不要害怕发布它。Jon Skeet 有一些很棒的内容，可以更深入地介绍这些实践，也可以引导您在此过程中解决自己的问题。特别是，他的提问清单^[5]和他对Stack Overflow 文化的^[6]看法都值得一读。

我个人在 Stack Overflow 上有过复杂的经历。那里的文化可能非常好管闲事，有些成员太快批评问题的措辞方式或是否可能重复。只要您已经做出合理的努力来搜索以前的答案，并花时间用代码示例形成一个精心设计的问题，尽量不要担心偶尔出现的糟糕响应。

通过这个博客，我通过评论或联系表收到了大量问题。我承认，我并不总是很擅长跟上。有时我发现这个问题太宽泛，需要太多时间才能完整回答。其他时候，由于措辞混乱或提出的要点太多，我什至不确定这个人真正需要什么帮助。

准备问题时，将自己置于接受者的位置。假设没有关于您的问题领域的先验知识，并确定您希望能够理解问题的核心信息是什么。专注于形成一个具体而简洁的问题，不会花费大量时间来解释和回答。我收到过电子邮件，其中的人只是想一口气问太多，我不知道他们需要了解什么才能解除封锁。我也收到过电子邮件，其中的人希望我采用单行要求并从本质上解释如何构建整个应用程序。这太宽泛了，我无法在个人时间回答。

我不是要让你在我上一段中提出问题。我想提醒你，另一端的人是人，有自己的工作和承诺。考虑到这一点，并确保您不会用含糊不清的问题不公平地垄断某人的时间。

询问同事

有些问题自然会更具体地针对您的工作地点及其产品。您可能想知道为什么优先使用特定的代码段而不是另一段代码。您可能不确定软件产品中的功能实际上是如何工作的。这些可能已经在公司 wiki 中被询问和回答。尽管如此，在许多情况下，答案可能永远不会被记录下来。在这些情况下，您需要亲自或通过聊天找到某人进行询问。您可能还会惊讶地发现，更多资深同事也不确定答案。这并不罕见，因为知识会随着时间流逝。您正在处理的代码可能是很久以前编写的，当时做出的决定可能不再明显。

我坚信没有愚蠢的问题。每个人的思维方式各不相同，对于一个人来说似乎很明显的事情，对于另一个人来说可能不太清楚。当有人提出一个精心设计的问题并表现出一些试图自己回答的迹象时，我更喜欢它。尽量简洁明了地提出你的问题，这样你问的人就可以快速弄清楚你想了解什么。此外，请务必在提问之前包含您已经知道或找到的任何相关信息。

与其说“这段代码做了什么？”，不如说“我试图理解这段代码的作用”。我在谷歌上搜索过，我可以看到它可能是 XYZ 模式，但我仍然不清楚它到底在做什么。没有针对代码的测试，所以我无法确认预期的行为。你能帮我吗？”

一个表明您已经在基础知识上花费时间，尝试自己调查并准备好您的想法的问题始终是首选。有时，您会面临时间压力，或者您可能担心自己破坏了一些重要的东西。最好根据自己的感觉尽早提出问题，而不是浪费宝贵的时间来尝试自己回答问题。

有时您可能能够根据研究完全回答问题，这太棒了。要求某人简单地验证您认为答案是什么也没有错。“我正在尝试理解这段代码，我相信它是 X，我认为它使用这种模式是因为 Y。我的理解是否正确？” 是一个完全有效的问题。

如何提问

一旦你尝试自己回答问题，如果你仍然需要一些帮助，你可能需要直接问别人这个问题。您的第一选择是谁最适合回答这个问题。尝试将您的查询定向到最合适的人。知道该问谁并不总是那么容易，因此联系您认识或共事的人以征求与谁交谈的建议是合理的。

一旦确定了要交谈的人，请考虑是否需要面对面交谈，或者其他方法是否更适合。您在此处的选择将取决于几个因素，例如您的问题有多复杂？有多紧急？这个人更喜欢如何参与？那个人有多忙？

作为一般规则，我建议通过您的内部聊天系统询问大多数问题。大多数公司使用一些异步消息服务，例如 Slack 或 Microsoft Teams。这些技术的优点是您可以避免打断与您交谈的人的交流。他们可以专注于自己的工作，直到有时间查看和回复聊天消息。

有些问题可能很容易通过聊天提出，您可以通过相同的媒介得到答案。有些将难以解释或可能需要一些来回讨论。这些最终可能会成为面对面的对话。首先，请考虑是否因为它很复杂而难以在聊天消息中写下您的问题。也许你需要先简化它。

橡皮鸭

顺便说一句，我之前曾在此博客^[7]上讨论过 Rubber Duck 的开发。有时，在提出问题时解释您的问题时，答案会突然出现在您身上。我们的大脑可以以神秘的方式工作，有时，我们需要换档来疏通自己。与面对面聊天相比，聊天消息的优势之一是您可以在撰写消息时回答自己的问题。在这种情况下，您不仅会得到答案，而且您甚至可能永远不会打断对方。他们可能在不知不觉中帮助了你。在我看来，这是一个真正的双赢。

当问题对于聊天来说太复杂时

聊天是一个很好的起点，但它并不适合我提到的每个问题。您询问的人可能会意识到这一点，并要求您亲自会面或通过视频会议。有时，您可能会发现它首先需要面对面。如果是这样，我建议避免开始参与，因为这样的中断真的会破坏某人的流程。在这种情况下，我建议您使用您的工作场所聊天工具向您的收件人发送消息，询问他们下次有空的时间。这样，他们就可以在做出响应之前专注于完成当前的任务。作为开发人员，我更喜欢有人以这种方式问我问题，因为如果在某些编码活动的关键时刻发生编码中断可能是真正的生产力杀手。

这个建议总会有奇怪的例外。如果您认为自己刚刚降低了生产量，请立即与人联系！

如果您有更一般的问题，请考虑您是否安排了一个可能是一个很好的论坛的会议。有时在会议上提出问题可以提供更多样化的意见，并使每个人都能从讨论中受益。不要害怕问什么感觉像是一个基本问题。如果您有问题，其他人也可能有问题。我离开了会议，大多数与会者实际上并不理解一些重要的事情，但所有人都不敢问，之后每个人都单独出现。

概括

无论您是为了成为软件开发人员而学习，还是大三的第一天，还是长期担任高级开发人员的高级开发人员，都不要害怕提问。求知是好事。它将帮助您成长并成为更好的开发人员。你会更深入地理解你的工作，并从你周围的人那里吸收想法和推理。

请记住，虽然没有愚蠢的问题，但存在形式不佳的问题。确保你的问题尽可能清晰和简洁。

分享相关信息和在询问之前，先做研究并尝试自己回答。如果您在此之后仍然需要帮助，请不要害怕提出您的问题。我们都时不时地需要帮助。

References

[1] Elastic: https://www.elastic.co/
[2] 曾在博客中介绍过: https://www.stevejgordon.co.uk/become-a-better-developer-by-reading-source-code
[3] Stack Overflow: http://stackoverflow.com/
[4] GitHub: https://github.com/
[5] 提问清单: https://codeblog.jonskeet.uk/2012/11/24/stack-overflow-question-checklist/
[6] Stack Overflow 文化的: https://codeblog.jonskeet.uk/2018/03/17/stack-overflow-culture/
[7] 在此博客: https://www.stevejgordon.co.uk/do-we-have-an-obsession-with-ducks-in-software-development/an-obsession-with-ducks