軟件開發過程當中的思惟方式 -- 如何分析問題

時間 2019-11-06

標籤軟件開發過程當中思惟方式如何分析問題简体版

原文原文鏈接

【這是 ZY 第 16 篇原創技術文章】html

今天這篇文章不談技術，想聊聊軟件開發過程當中的一些思惟方式，以及如何去深刻挖掘問題的核心，如何去看清問題的本質。設計模式

1、分析問題的重要性

咱們在軟件開發過程當中，每每會遇到不少問題，無論是對需求合理性的探討，仍是對開發過程當中 bug 緣由的排查，仍是對線上問題的追溯，都體現了分析問題的重要性。bash

只有挖掘出問題的核心和根本，才能 針對性的提出改進或者完善流程，來避免相似的問題再次出現。
其實做者以前對這方面是不在在乎的，認爲分析問題很簡單，每每是找到最直接的緣由便可。直到最近看了一些 case 的分析，瞭解到了一些分析問題的思惟方法，才發現其實沒有想象的那麼簡單。架構

舉個栗子：
咱們在開發過程當中出現 bug 是不可避免的。有時候因爲測試不充分，還會將 bug 帶入線上。
咱們假設如今有一個 Android 屏幕適配的問題，致使某些機型上控件展現不完整。咱們是如何反思問題的呢？框架

由於不知道你們的狀況，這裏以做者本人來講，在之前分析問題時，基本上是以下的思惟：
由於 Android 碎片化的問題，Android 屏幕適配的問題實際上是不少的，此次的緣由主要是由於開發測試過程當中對不一樣機型測試不充分。後面的改進就是儘可能測試更多機型，減小適配問題。學習

讀者朋友們能夠對照上面的回答進行反思，看看本身是如何思考這個問題的。測試

給你們三分鐘的時間思考，而後咱們來看看我最近接觸到的幾種分析方法，是如何針對上面的問題進行分析的。spa

這裏想分享給你們兩種思惟方式：5WHY 分析法和第一性原理。.net

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 人工檢查，畢竟人工總會存在遺漏。
那麼咱們的解決方案就是，可否經過一些自動化手段，來對這類問題進行檢查。

經過上面十二個問題，咱們針對線上的屏幕適配問題，提出了五種對應的改進：

開發者要吸收經驗，儘可能採用普適性較強的寫法
對一些組件進行封裝，避免相似的適配問題
有新設備上市，要儘早採購
QA 的測試用例要多人評審，儘可能保證用例覆蓋全面
經過一些自動化檢測手段，對適配問題進行檢測

相比咱們文章開頭的思考，經過 5WHY 分析法 的不斷提問，是否是對問題的理解更加深刻，更能逼近問題的根源，也能採起更加針對性的措施。

固然，上面的例子中會有虛構的成分，目的是想給讀者朋友們展示不斷提問的好處。
並且不止軟件開發的問題，遷移到生活中學習中的問題，也是可使用 5why 分析法的。
讀者朋友們在後面的工做學習中，能夠多嘗試，力爭找到問題的根源。

3、第一性原理 (First Principles)

第一性原理是古希臘哲學家亞里士多德提出的一個哲學術語：每一個系統中存在一個最基本的命題，它不能被違背或刪除。
馬斯克也不止一次提到過他對第一性原理的思考。

咱們運用「第一原理思惟」而不是「比較思惟」去思考問題是很是重要的。咱們在生活中老是傾向於比較——別人已經作過了或者正在作這件事情，咱們就也去作。這樣的結果是隻能產生細小的迭代發展。「第一原理」的思考方式是用物理學的角度看待世界的方法，也就是說一層層剝開事物的表象，看到裏面的本質，而後再從本質一層層往上走。這要消耗大量的腦力。

第一性原理解讀

咱們這裏對第一性原理作些解讀。

摘自：www.huxiu.com/article/250…
在哲學領域裏，第一性原理指的是「先驗」（a priori），也就是不依賴任何經驗和邏輯的，也沒法用理性推導獲得的東西。能夠說，它們是理性思考的起點，是公認的、不容被質疑、也沒法證實的。一般它和認識論有關，康德說的「純粹理性」之因此「純粹」，緣由就在這裏。在物理學裏，第一性原理指的是「從頭算」（ab initio），意思是直接來自已經創建的物理規律，而不依賴任何經驗模型。好比根據若干公理，用薛定諤方程來計算電子結構，而不考慮任何實驗數據，就能夠稱做「從頭算」的計算。

在哲學和物理學的領域，第一性原理強調的是本質，是公理。看到這裏，其實咱們都運用過第一性原理，回想咱們初高中時候作數學物理證實題，都是基於公理，一步一步推導。

而在馬斯克的的解讀中，第一性原理是和比較思惟作對比的。比較思惟傾向於看別人怎麼作這件事，而後咱們在其基礎上去作改進。與此相反的第一性原理，就是要追尋事物的本質，探尋事物的起源，避免被其餘人影響。

軟件開發中的第一性原理

那第一性原理在軟件開發過程當中有什麼用呢？咱們也要抓住開發過程當中的本質。
主要想從下面 3 點來分享個人思考：

開發問題的本質--官方文檔
先說說我目前觀察到的一些狀況，在開發過程當中，咱們遇到問題是屢見不鮮，所以要去查找資料，查找文檔，大多數狀況下，咱們會看一些博客文章。可是說實話，如今文章不少，每每看了很長時間，也無法找到解決方法。
這時咱們不如直接去讀官方文檔，去讀 SDK，去讀源碼，每每來的更快一點。這裏的官方文檔，SDK，源碼，就至關於第一性原理中的公理。這一點其實我深有體會，因此這裏也是給我本身的建議，有問題時，運用第一性原理，多讀官方文檔。
閱讀源碼的本質--優秀框架背後的設計模式和架構
咱們常常會讀一些優秀的開源項目代碼，每每會發現一些優秀的架構或者寫法，這時候咱們也能夠運用第一性原理，想一想這種寫法的原理是什麼，根源是什麼，每每就會追溯到設計模式或者架構模式上。而後咱們就能夠去深刻了解其根源。而不僅停留在表面的模仿上。
開發的本質--知足需求
咱們作爲軟件開發者，工做是寫代碼，開發軟件，做爲對技術有追求的人，咱們每每會執着於追求技術。
但往深處想一想，咱們做爲開發者，其實工做是在知足需求。業務開發，知足的是用戶的需求。技術開發，知足的是其餘開發者的需求。
當了解這個本質之後，咱們就能夠多從需求的角度去思考一些問題，一些難以用技術解決的問題，能夠從需求的角度去解決。

4、對方法論的一些思考

5WHY 分析法和第一性原理，就是這篇文章想分享給讀者朋友們的兩個思惟方式。
5WHY 分析法重在問題產生後進行分析，經過一系列的層層追問探尋問題的根源和本質，以針對性的解決問題。
第一性原理，重在探尋事物的本質，儘可能避免他人的干擾。

最後，想談談我的對 方法論 的一些思考。
有些公司內部會比較強調方法論。而不少人對此詬病頗多，認爲是流於形式，不追求實質。
我以前也是這樣認爲的，不過最近有了改觀。我的對方法論的理解是這樣的：方法論必須存在，可是不能拘泥於此。
如何講呢？

首先是方法論必需要存在
方法論是咱們觀察事物，處理問題總結的一套理論體系或者系統，是大量實踐之後總結的經驗。爲何必需要存在呢？由於方法論的存在，能夠更好的指導後續的工做學習生活。有了方法論的指導，後面的探索過程會大大減小。
有些讀者朋友可能會說，我不使用方法論，也能夠很好的解決問題。（不瞞你們說，我以前也是這樣想的）。後來我想清楚了這個問題中的關鍵點，若是解決問題的方式，每次都有必定的套路，必定的流程，其實這個時候已經造成了本身的一套方法論，只不過沒有白紙黑字寫出來而已。若是每次解決問題的方式老是在變化，那隻能說是運氣使然，解決問題剛好碰到對應的方法，就至關於段譽的六脈神劍同樣，時而有效時而無效。
不能拘泥於此
方法論的造成，能夠指導後續的工做學習生活，可是問題老是在變化，因此不能拘泥於已經造成的方法論，而是要在變化中運用，不斷擴充，修改，再具體問題具體對待。

上面就是我的對軟件開發過程當中思惟方式的一些思考，但願能幫助到讀者朋友們。