软件开发思维方式之看清问题的本质

问题导读：
1、解读分析问题的重要性？
2、如何理解5WHY 分析法？
3、如何理解第一性原理？
4、对方法论的思考内容有哪些？



今天这篇文章不谈技术，想聊聊软件开发过程中的一些思维方式，以及如何去深入挖掘问题的核心，如何去看清问题的本质。

一、分析问题的重要性
我们在软件开发过程中，往往会遇到很多问题，不管是对需求合理性的探讨，还是对开发过程中 bug 原因的排查，还是对线上问题的追溯，都体现了分析问题的重要性。
只有挖掘出问题的核心和根本，才能 针对性的提出改进或者完善流程，来避免类似的问题再次出现。
其实作者之前对这方面是不在在意的，认为分析问题很简单，往往是找到最直接的原因即可。直到最近看了一些 case 的分析，了解到了一些分析问题的思维方法，才发现其实没有想象的那么简单。

举个栗子：
我们在开发过程中出现 bug 是不可避免的。有时候由于测试不充分，还会将 bug 带入线上。
我们假设现在有一个 Android 屏幕适配的问题，导致某些机型上控件展示不完整。我们是如何反思问题的呢？
因为不知道大家的情况，这里以作者本人来说，在以前分析问题时，基本上是如下的思维：
因为 Android 碎片化的问题，Android 屏幕适配的问题其实是很多的，这次的原因主要是因为开发测试过程中对不同机型测试不充分。后面的改进就是尽量测试更多机型，减少适配问题。
读者朋友们可以对照上面的回答进行反思，看看自己是如何思考这个问题的。
给大家三分钟的时间思考，然后我们来看看我最近接触到的几种分析方法，是如何针对上面的问题进行分析的。
这里想分享给大家两种思维方式：5WHY 分析法 和 第一性原理。

二、5WHY 分析法
先来看看 5WHY 分析法，这种方法最初是由丰田佐吉提出的，后来，丰田汽车公司在发展完善其制造方法学的过程之中也采用了这一方法。

下面内容摘自5WHY 分析法。

所谓 5WHY 分析法，又称“5问法”，也就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。5why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。

所以 5WHY 分析法的核心是 追究根本原因。

我们可以看一个经典的例子：
丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正原因
问题一：为什么机器停了？
答案一：因为机器超载，保险丝烧断了。

问题二：为什么机器会超载？
答案二：因为轴承的润滑不足。

问题三：为什么轴承会润滑不足？
答案三：因为润滑泵失灵了。

问题四：为什么润滑泵会失灵？
答案四：因为它的轮轴耗损了。

问题五：为什么润滑泵的轮轴会耗损？
答案五：因为杂质跑到里面去了。

经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。
如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。
通过上面的例子，可以比较清晰的看出来，针对问题，要层层深入，直到找到最终原因。

实施层面
5WHY 从三个层面来实施：

一、为什么会发生？从“制造”的角度。
二、为什么没有发现？从“检验”的角度。
三、为什么没有从系统上预防事故？从“体系”或“流程”的角度。

实例分析
我们运用 5WHY 分析法来实战一下，以文章开头的例子来看，线上出现屏幕适配问题，如何反思。
问题一：为什么会出现屏幕适配问题？
答案一：因为开发过程中没有对多机型进行测试

问题二：为什么没有测试就会出现适配问题？
答案二：因为控件使用了固定的高度

问题三：为什么不使用自适应高度，而要使用固定高度？
答案三：因为 UI 稿上标注了高度，所以就直接用了

问题四：为什么直接使用 UI 稿标注高度，不考虑采用一些适应性较强的写法？
答案四：因为开发经验不足，开发时没有考虑到这个问题

到这里，我们能看出根本问题是由于开发经验不足，没有考虑适配的问题。
那我们的解决方法就是，把此次问题就当做一个经验教训，在后面开发中 采用普适性较强的写法 来做，从根本上杜绝适配问题。
如果仅仅根据文章开始的浅显分析，我们只是说后面会多测机型，并没有从根源上重视问题。
然后我们再往下提问。

问题五：为什么不使用现有的适配性较强的组件？
答案五：因为此组件比较简单，所以没有进行封装

到这里，我们可以思考一下，是不是可以对一些适配性的组件进行封装，避免后续开发过程中的问题。

然后我们再往下提问。
问题六：为什么 QA 测试过程中没有发现？
答案六：因为 QA 没有这款设备

问题七：为什么没有这款设备？
答案七：因为这款设备是上市不久，还没有进行采购

问题八：为什么没有进行设备采购？
答案八：因为没有报备
到这里，我们会发现，开发过程中的问题，在测试阶段没有暴露，是因为测试设备采购不及时。
那么我们的解决方法就是，尽量提早采购新设备，尽量提前报备。

然后再往下提问。
问题九：QA 手中其他设备存在类似问题吗？
答案九：有其他设备也存在类似问题

问题十：为什么没有在其他设备上测试出这个问题？
答案十：因为没有测试对应的用例

问题十一：为什么没有测试对应的用例？
答案十一：因为 QA 在设计测试用例时没有考虑到类似的情况

到这里我们会发现，因为测试用例设计不足，导致没有暴露问题。
那么我们的解决方法就是，测试用例可以让多人评审，尽可能保证用例覆盖全面。

然后还能再往下提问。
问题十二：为什么上线前没有此类问题的检查？
答案十二：因为目前都是通过 QA 人工确认问题，因为 QA 那边没有反馈问题，所以认为不存在问题

到这里我们会发现，目前上线都是通过 QA 人工检查，毕竟人工总会存在遗漏。
那么我们的解决方案就是，能否通过一些自动化手段，来对这类问题进行检查。

通过上面十二个问题，我们针对线上的屏幕适配问题，提出了五种对应的改进：

• 开发者要吸取经验，尽量采用普适性较强的写法
• 对一些组件进行封装，避免类似的适配问题
• 有新设备上市，要尽早采购
• QA 的测试用例要多人评审，尽量保证用例覆盖全面
• 通过一些自动化检测手段，对适配问题进行检测
  

相比我们文章开头的思考，通过 5WHY 分析法 的不断提问，是不是对问题的理解更加深入，更能逼近问题的根源，也能采取更加针对性的措施。
当然，上面的例子中会有虚构的成分，目的是想给读者朋友们展现不断提问的好处。
而且不止软件开发的问题，迁移到生活中学习中的问题，也是可以使用 5why 分析法的。
读者朋友们在后面的工作学习中，可以多尝试，力争找到问题的根源。

三、第一性原理 (First Principles)
第一性原理是古希腊哲学家亚里士多德提出的一个哲学术语：每个系统中存在一个最基本的命题，它不能被违背或删除。
马斯克也不止一次提到过他对第一性原理的思考。

我们运用「第一原理思维」而不是「比较思维」去思考问题是非常重要的。我们在生活中总是倾向于比较——别人已经做过了或者正在做这件事情，我们就也去做。这样的结果是只能产生细小的迭代发展。「第一原理」的思考方式是用物理学的角度看待世界的方法，也就是说一层层剥开事物的表象，看到里面的本质，然后再从本质一层层往上走。这要消耗大量的脑力。

第一性原理解读
我们这里对第一性原理做些解读。

在哲学领域里，第一性原理指的是“先验”（a priori），也就是不依赖任何经验和逻辑的，也无法用理性推导得到的东西。可以说，它们是理性思考的起点，是公认的、不容被质疑、也无法证明的。通常它和认识论有关，康德说的“纯粹理性”之所以“纯粹”，原因就在这里。

在物理学里，第一性原理指的是“从头算”（ab initio），意思是直接来自已经建立的物理规律，而不依赖任何经验模型。比如根据若干公理，用薛定谔方程来计算电子结构，而不考虑任何实验数据，就可以称作“从头算”的计算。

在哲学和物理学的领域，第一性原理强调的是本质，是公理。
看到这里，其实我们都运用过第一性原理，回想我们初高中时候做数学物理证明题，都是基于公理，一步一步推导。
而在马斯克的的解读中，第一性原理是和比较思维做对比的。比较思维倾向于看别人怎么做这件事，然后我们在其基础上去做改进。与此相反的第一性原理，就是要追寻事物的本质，探寻事物的起源，避免被其他人影响。

软件开发中的第一性原理
那第一性原理在软件开发过程中有什么用呢？我们也要抓住开发过程中的本质。
主要想从下面 3 点来分享我的思考：

• 开发问题的本质--官方文档
  

先说说我目前观察到的一些情况，在开发过程中，我们遇到问题是家常便饭，因此要去查找资料，查找文档，大多数情况下，我们会看一些博客文章。但是说实话，现在文章很多，往往看了很长时间，也没法找到解决方法。
这时我们不如直接去读官方文档，去读 SDK，去读源码，往往来的更快一点。这里的官方文档，SDK，源码，就相当于第一性原理中的公理。
这一点其实我深有体会，所以这里也是给我自己的建议，有问题时，运用第一性原理，多读官方文档。

• 阅读源码的本质--优秀框架背后的设计模式和架构
  

我们经常会读一些优秀的开源项目代码，往往会发现一些优秀的架构或者写法，这时候我们也可以运用第一性原理，想想这种写法的原理是什么，根源是什么，往往就会追溯到设计模式或者架构模式上。然后我们就可以去深入了解其根源。而不只停留在表面的模仿上。

• 开发的本质--满足需求
  

我们做为软件开发者，工作是写代码，开发软件，作为对技术有追求的人，我们往往会执着于追求技术。
但往深处想想，我们作为开发者，其实工作是在满足需求。业务开发，满足的是用户的需求。技术开发，满足的是其他开发者的需求。
当了解这个本质以后，我们就可以多从需求的角度去思考一些问题，一些难以用技术解决的问题，可以从需求的角度去解决。


四、对方法论的一些思考
5WHY 分析法 和 第一性原理，就是这篇文章想分享给读者朋友们的两个思维方式。
5WHY 分析法重在问题产生后进行分析，通过一系列的层层追问探寻问题的根源和本质，以针对性的解决问题。
第一性原理，重在探寻事物的本质，尽量避免他人的干扰。
最后，想谈谈个人对 方法论 的一些思考。
有些公司内部会比较强调方法论。而很多人对此诟病颇多，认为是流于形式，不追求实质。
我之前也是这样认为的，不过最近有了改观。
个人对方法论的理解是这样的：方法论必须存在，但是不能拘泥于此。
如何讲呢？

• 首先是方法论必须要存在
  

方法论是我们观察事物，处理问题总结的一套理论体系或者系统，是大量实践以后总结的经验。为什么必须要存在呢？因为方法论的存在，可以更好的指导后续的工作学习生活。有了方法论的指导，后面的探索过程会大大减少。
有些读者朋友可能会说，我不使用方法论，也可以很好的解决问题。（不瞒大家说，我之前也是这样想的）。后来我想清楚了这个问题中的关键点，如果解决问题的方式，每次都有一定的套路，一定的流程，其实这个时候已经形成了自己的一套方法论，只不过没有白纸黑字写出来而已。如果每次解决问题的方式总是在变化，那只能说是运气使然，解决问题恰好碰到对应的方法，就相当于段誉的六脉神剑一样，时而有效时而无效。

• 不能拘泥于此
  

方法论的形成，可以指导后续的工作学习生活，但是问题总是在变化，所以不能拘泥于已经形成的方法论，而是要在变化中运用，不断扩充，修改，再具体问题具体对待。

上面就是个人对软件开发过程中思维方式的一些思考，希望能帮助到读者朋友们。

作者：ZYLAB
来源：https://juejin.im/post/5d8ccb40f265da5b6723d71f

最新经典文章，欢迎关注公众号

学习了，谢谢分享

感谢分享