软件开发过程当中的思惟方式 -- 如何分析问题

【这是 ZY 第 16 篇原创技术文章】

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

1、分析问题的重要性

咱们在软件开发过程当中，每每会遇到不少问题，无论是对需求合理性的探讨，仍是对开发过程当中 bug 缘由的排查，仍是对线上问题的追溯，都体现了分析问题的重要性。

只有挖掘出问题的核心和根本，才能 针对性的提出改进或者完善流程，来避免相似的问题再次出现。
其实做者以前对这方面是不在在乎的，认为分析问题很简单，每每是找到最直接的缘由便可。直到最近看了一些 case 的分析，了解到了一些分析问题的思惟方法，才发现其实没有想象的那么简单。

举个栗子：
咱们在开发过程当中出现 bug 是不可避免的。有时候因为测试不充分，还会将 bug 带入线上。
咱们假设如今有一个 Android 屏幕适配的问题，致使某些机型上控件展现不完整。咱们是如何反思问题的呢？

由于不知道你们的状况，这里以做者本人来讲，在之前分析问题时，基本上是以下的思惟：
由于 Android 碎片化的问题，Android 屏幕适配的问题实际上是不少的，此次的缘由主要是由于开发测试过程当中对不一样机型测试不充分。后面的改进就是尽可能测试更多机型，减小适配问题。

读者朋友们能够对照上面的回答进行反思，看看本身是如何思考这个问题的。

给你们三分钟的时间思考，而后咱们来看看我最近接触到的几种分析方法，是如何针对上面的问题进行分析的。

这里想分享给你们两种思惟方式：5WHY 分析法 和 第一性原理。

2、5WHY 分析法

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

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

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

因此 5WHY 分析法的核心是 追究根本缘由。

咱们能够看一个经典的例子：

丰田汽车公司前副社长大野耐一曾举了一个例子来找出停机的真正缘由
问题一：为何机器停了？
答案一：由于机器超载，保险丝烧断了。

问题二：为何机器会超载？
答案二：由于轴承的润滑不足。

问题三：为何轴承会润滑不足？
答案三：由于润滑泵失灵了。

问题四：为何润滑泵会失灵？
答案四：由于它的轮轴耗损了。

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

通过连续五次不停地问“为何”，才找到问题的真正缘由和解决的方法，在润滑泵上加装滤网。
若是员工没有以这种追根究底的精神来发掘问题，他们极可能只是换根保险丝草草了事，真正的问题仍是没有解决。
复制代码

经过上面的例子，能够比较清晰的看出来，针对问题，要层层深刻，直到找到最终缘由。

实施层面

5WHY 从三个层面来实施：

1、为何会发生？从“制造”的角度。
2、为何没有发现？从“检验”的角度。
3、为何没有从系统上预防事故？从“体系”或“流程”的角度。

实例分析

咱们运用 5WHY 分析法来实战一下，以文章开头的例子来看，线上出现屏幕适配问题，如何反思。

问题一：为何会出现屏幕适配问题？
答案一：由于开发过程当中没有对多机型进行测试

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

问题三：为何不使用自适应高度，而要使用固定高度？
答案三：由于 UI 稿上标注了高度，因此就直接用了

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

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

而后咱们再往下提问。

问题五：为何不使用现有的适配性较强的组件？
答案五：由于此组件比较简单，因此没有进行封装
复制代码

到这里，咱们能够思考一下，是否是能够对一些适配性的组件进行封装，避免后续开发过程当中的问题。

而后咱们再往下提问。

问题六：为何 QA 测试过程当中没有发现？
答案六：由于 QA 没有这款设备

问题七：为何没有这款设备？
答案七：由于这款设备是上市不久，尚未进行采购

问题八：为何没有进行设备采购？
答案八：由于没有报备
复制代码

到这里，咱们会发现，开发过程当中的问题，在测试阶段没有暴露，是由于测试设备采购不及时。 那么咱们的解决方法就是，尽可能提前采购新设备，尽可能提早报备。

而后再往下提问。

问题九：QA 手中其余设备存在相似问题吗？
答案九：有其余设备也存在相似问题

问题十：为何没有在其余设备上测试出这个问题？
答案十：由于没有测试对应的用例

问题十一：为何没有测试对应的用例？
答案十一：由于 QA 在设计测试用例时没有考虑到相似的状况
复制代码

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

而后还能再往下提问。

问题十二：为何上线前没有此类问题的检查？
答案十二：由于目前都是经过 QA 人工确认问题，由于 QA 那边没有反馈问题，因此认为不存在问题
复制代码

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

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

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

相比咱们文章开头的思考，经过 5WHY 分析法 的不断提问，是否是对问题的理解更加深刻，更能逼近问题的根源，也能采起更加针对性的措施。

固然，上面的例子中会有虚构的成分，目的是想给读者朋友们展示不断提问的好处。
并且不止软件开发的问题，迁移到生活中学习中的问题，也是可使用 5why 分析法的。
读者朋友们在后面的工做学习中，能够多尝试，力争找到问题的根源。

3、第一性原理 (First Principles)

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

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

第一性原理解读

咱们这里对第一性原理作些解读。

摘自：www.huxiu.com/article/250…
在哲学领域里，第一性原理指的是“先验”（a priori），也就是不依赖任何经验和逻辑的，也没法用理性推导获得的东西。能够说，它们是理性思考的起点，是公认的、不容被质疑、也没法证实的。一般它和认识论有关，康德说的“纯粹理性”之因此“纯粹”，缘由就在这里。 在物理学里，第一性原理指的是“从头算”（ab initio），意思是直接来自已经创建的物理规律，而不依赖任何经验模型。好比根据若干公理，用薛定谔方程来计算电子结构，而不考虑任何实验数据，就能够称做“从头算”的计算。

在哲学和物理学的领域，第一性原理强调的是本质，是公理。 看到这里，其实咱们都运用过第一性原理，回想咱们初高中时候作数学物理证实题，都是基于公理，一步一步推导。

而在马斯克的的解读中，第一性原理是和比较思惟作对比的。比较思惟倾向于看别人怎么作这件事，而后咱们在其基础上去作改进。与此相反的第一性原理，就是要追寻事物的本质，探寻事物的起源，避免被其余人影响。

软件开发中的第一性原理

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

1. 开发问题的本质--官方文档
   先说说我目前观察到的一些状况，在开发过程当中，咱们遇到问题是屡见不鲜，所以要去查找资料，查找文档，大多数状况下，咱们会看一些博客文章。可是说实话，如今文章不少，每每看了很长时间，也无法找到解决方法。
   这时咱们不如直接去读官方文档，去读 SDK，去读源码，每每来的更快一点。这里的官方文档，SDK，源码，就至关于第一性原理中的公理。 这一点其实我深有体会，因此这里也是给我本身的建议，有问题时，运用第一性原理，多读官方文档。

2. 阅读源码的本质--优秀框架背后的设计模式和架构
   咱们常常会读一些优秀的开源项目代码，每每会发现一些优秀的架构或者写法，这时候咱们也能够运用第一性原理，想一想这种写法的原理是什么，根源是什么，每每就会追溯到设计模式或者架构模式上。而后咱们就能够去深刻了解其根源。而不仅停留在表面的模仿上。

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

4、对方法论的一些思考

5WHY 分析法 和 第一性原理，就是这篇文章想分享给读者朋友们的两个思惟方式。
5WHY 分析法重在问题产生后进行分析，经过一系列的层层追问探寻问题的根源和本质，以针对性的解决问题。
第一性原理，重在探寻事物的本质，尽可能避免他人的干扰。

最后，想谈谈我的对 方法论 的一些思考。
有些公司内部会比较强调方法论。而不少人对此诟病颇多，认为是流于形式，不追求实质。
我以前也是这样认为的，不过最近有了改观。 我的对方法论的理解是这样的：方法论必须存在，可是不能拘泥于此。
如何讲呢？

1. 首先是方法论必需要存在
   方法论是咱们观察事物，处理问题总结的一套理论体系或者系统，是大量实践之后总结的经验。为何必需要存在呢？由于方法论的存在，能够更好的指导后续的工做学习生活。有了方法论的指导，后面的探索过程会大大减小。
   有些读者朋友可能会说，我不使用方法论，也能够很好的解决问题。（不瞒你们说，我以前也是这样想的）。后来我想清楚了这个问题中的关键点，若是解决问题的方式，每次都有必定的套路，必定的流程，其实这个时候已经造成了本身的一套方法论，只不过没有白纸黑字写出来而已。若是每次解决问题的方式老是在变化，那只能说是运气使然，解决问题刚好碰到对应的方法，就至关于段誉的六脉神剑同样，时而有效时而无效。

2. 不能拘泥于此
   方法论的造成，能够指导后续的工做学习生活，可是问题老是在变化，因此不能拘泥于已经造成的方法论，而是要在变化中运用，不断扩充，修改，再具体问题具体对待。

上面就是我的对软件开发过程当中思惟方式的一些思考，但愿能帮助到读者朋友们。

参考资料

baike.baidu.com/item/5why分析…
www.huxiu.com/article/250…
www.woshipm.com/pmd/841189.…
old.geekpark.net/topics/2123…