问题解决者-CSDN博客

我将以引号开头这篇文章：

“您认识的每一个伟大的开发人员都是通过解决问题来解决问题的，直到他们真正解决问题为止。” –帕特里克·麦肯齐

— The Practical Dev（@ThePracticalDev） 2017年2月14日

好的开发者是解决问题的好人。他们将每个任务转化为一系列必须解决的问题。他们不一定事先知道如何解决，但他们拥有解决方案的方法，快捷方式和其他技巧的工具箱。我已经概述了识别问题的此类步骤，但是您不能轻松地将问题解决方法正式化。

但是，将一项任务变成一系列问题真的是一个好主意吗？编程可以被视为一种创造性的练习，而不是解决问题的一种练习–您认为，思考，深思熟虑，然后便凭空创造出一些东西，而且它很漂亮，因为它可以工作。有时就是那样编程，但这几乎总是被一系列使您无法完成任务的问题打断。通过以下短视频可以最好地看到该过程：

那是因为软件中的大多数事情都中断了。它们要么因为未知而中断，要么是由于很多不可预见的边缘情况，或者是因为我们使用的抽象方法泄漏，或者因为我们使用的工具的文档记载不充分或API / UI不良，或者仅仅是因为有错误。或在许多情况下–以上所有。

因此，不可避免地，我们必须学会解决问题。也许有人会争辩说，事实上，快速正确地解决它们是做软件时最重要的技能。但是，人们应该学会的不仅是用胶带捆扎东西，而且要想出最好的解决方案，并附带约束。您正在使用的库缺少您真正需要的功能？理想情况下，您应该提出该功能并等待其实现。很多时候，这不是一个选择。快速而肮脏的修复程序–复制粘贴一堆代码。正确，优雅的解决方案–使用设计模式使库适应您的需求，或者提出修补库的通用方法（但不会浪费时间）。还是有内存泄漏？只是启动一个更大的实例？否。要花一周的时间对应用程序进行性能分析吗？要慢。弄清楚如何在本地设置中模拟泄漏场景并在一天内解决？听起来很理想，但并不简单。

有时问题不会太多，发展会顺利进行。然后，好的问题解决者可以主动发现问题-这种实现速度慢，占用内存过多，过于复杂，应进行重构。这些可以（并且应该）是不干扰开发过程的小步骤，没有明显的理由，就使您有2天的深度重构时间。该技能是要在逐步改进和发现问题之前发现它们之间的界限，并浪费时间在不存在或您永远不会遇到的问题上。

最后，解决问题不是一个单独的练习。实际上，我认为解决问题的最重要方面之一就是回答问题。如果您想成为一名优秀的开发人员，则必须回答其他人的问题。您的同事在大多数情况下，但有时是– Stackoverflow上的陌生人。我自己发现，回答stackoverflow问题实际上使我成为一个更好的问题解决者–我可以在有限的时间内用有限的信息解决其他问题。因此，在很多情况下，即使我不是最资深或最不熟悉该项目的人，在出现问题时我都是团队的负责人。但是可以合理地期望我将能够Swift找到一种合适的解决方案。然后循环继续进行–您回答更多的问题，并在解决问题上变得更好，等等，依此类推。顺便说一句，除非我们能够解决我们自己之外的其他问题，否则我们不应该认为自己是好人。

解决问题是一项可转让的技能。我们可能不会永远成为开发人员，但是在许多情况下，我们解决问题的方法，解决问题的坚韧态度以及决心正确完成工作的决心都是有用的。实际上，您可以将每个任务（不仅仅是编程任务）视为解决问题的练习。而且，即使您以前从未遇到过，也有信心可以修复它，这通常是无价的。

我的最终目的是什么？我们应该将自己视为问题解决者，并不断改进我们的问题解决工具箱。其中包括帮助他人。否则，我们会被束缚于对特定技术或堆栈的了解，这很无聊。