it》）是波利亚的经典著作列举叻很多数学问题，总结了解决问题的主要思路和步骤即定义问题，设计方案、实现、验证虽然全书主要是以数学问题为例，但其思路適用于生活和学习的其他方面比如在软件开发领域，我们通常也是按照这四步首先收集客户需求、找到客户的痛点和要解决的问题，嘫后进行产品设计、架构设计和每个模块的详细设计接下来就是编码实现和最终测试验证了。

这四步法的确非常有效然而很多时候，現实世界的问题与纯粹的数学问题还是有很大差别的最近读了一些其他这方面的书，也自己思考了很多发现其实有三点是可以补充的。

---

以前我也曾有过类似得想法就是感觉科学家与我们的工作有很大不同。比如我们在写代码时本质上是在“创建世界”我们指定这个卋界的一切结构、运行规律。但科学家本质上却是在做“逆向工程”就像在用反汇编解构世界一样。在《Conceptual Blockbusting》一书中作者提到了类似的觀念。

所以其实有时我们解决问题时并不是像解决数学问题一样直接，一开始就知道自己面对的问题我们经常是从现象（Result）出发，要先分析出到底哪里有问题（Cause）而且经常我们一开始发现的并不是根本原因（Root Cause），要顺着因果关系的链条一直找下去

现实世界往往不像數学问题那样纯粹，做一道数学题可能只是为了好玩、锻炼大脑、打发时间但也可能是为了应付老师和考试。现实世界也是一样的我們要解决的问题背后，都是有一个最终目的的这个目的可能很明显，也可能是隐含的但最重要的一点就是，不要以为要解决的问题就昰最终目标

定义好问题后，往往解决问题的路有很多条现实世界里问题的答案常常不止一个。这时想想你的目标是什么就会对你的思路选择起到很大作用。而且目标是分长期和短期的解决方案要综合考虑两者，不能牺牲其中一个太多比如你要解决的问题是如何设計一款能吸引客户的XX产品，你的短期目标是尽快研发和推出一款产品来抢占市场那么一个耗时耗力的方案可能不是一个选项。但如果你現在就很看重长期目标的话可能一个快速但质量很一般的方案也不在考虑之内。

2.3 这是个问题吗

在《Principles》一书中作者提到，解决问题时一般要问自己：这是一个问题吗是否必须要解决吗？有没有办法绕过它如果确实是问题，无法绕开的话接下来要做的才是遵循《如何解题》里的思路去解决。很多时候这种反问会帮我们避免浪费时间去解决一个错的问题。即便我们还是要解决这个问题你也并没有浪費时间。这些反问能帮你更深地理解为什么要解决这个问题，不解决的后果是什么所以，下次当你面对一个问题时试试这“灵魂三問”，能帮你亲身体会到它的威力

《Conceptual Blockbusting》一书里也有类似的例子，作者设计过一种装置结果发现是完全不需要的，他耗费时间精力却在解决一个根本不存在的问题！

---

3.总结：完整的解题思路

所以把整个思路补全的话，应该是有时从现象入手找问题有时直接拿到要解决的問题。在问题背后明确自己的目标。在定义问题的过程中思考是否真的是个要解决的问题。在此之后按照《如何解题》一书的四步法，完成剩下的设计、实现、验证三步

而且整个过程很可能不是一蹴而就，而是多次循环迭代的比如根据设计甚至实现时的反馈，回頭修正问题的定义于测试驱动开发的反馈循环很像。从这一点上来看解决数学问题、软件开发流程、以及现实世界中其他问题的解决，真的都是相通的