观察者模式解决了什么问题_问题解决者

观察者模式解决了什么问题

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

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

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

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

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

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

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

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

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

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

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

翻译自: https://www.javacodegeeks.com/2017/11/the-problem-solver.html

观察者模式解决了什么问题