很多開發者，將自己限定為程式設計師，覺得自己就是一個專業寫程式碼的，和程式碼稍微遠一點東西，就不感興趣。
在前一篇文章 《軟體開發之未來》 中， 我已經闡述了技術的時效性以及快速更新。
如果我們緊緊把目光侷限在程式碼，而不是分析、解決問題的綜合能力，我們將遲早陷入中年危機， 被奔騰的技術潮流淘汰。
這篇文章我想講講分析問題、解決問題的基本套路，這是我多年總結下來的習慣，希望對大家有幫助。
絕對不是立刻寫程式碼
有些同學鍾情程式碼，收到一個任務，馬上就想到程式碼實現。
問題都還沒弄清楚，工作原理還沒分析透，就開始整出幾個類，然後思考如何用這些類。
找人討論，直接看程式碼。
這是準備死 1000 次的節奏。
動筆頭: 設計文件
有些新人，很有責任心，碰到問題也會找我溝通討論。 但是怎麼也不能深入下去，執行效果千瘡百孔，各種返工改進，考慮不周，不能產品化，彎路不少。
問題在於，不善於動筆頭。動筆頭的目的:
1、沉澱思考結果：
每次思考，每次討論，達成一步認識，就固定下來。上一步臺階，步步為營才能達到目標。
如果不記錄，就會焦慮，就會低水平原地重複思考。
大多數人的大腦記憶體有限，必須藉助文件這種外存進行交換才能順暢執行的。
2、文件是 alpha 版本的程式
大腦就是執行文件的計算機。
看一遍文件，讓整個系統在執行之前，在大腦裡面執行一遍。
每次執行一遍，才能發現是否會丟擲異常。對這些異常，在文件修正。然後再次執行，再次尋找處理異常。
不僅僅在自己大腦執行，還要通過設計評審在別人大腦執行。如果有多種方案，需要大家進行評測那條最佳。
不可能一次就做好設計，只有反覆執行，多處執行，才能最終出錯可能性最小。
因此文件是否清晰明瞭是否簡單，非常非常關鍵。
設計文件我推薦採用幻燈片的形式，因為一個頁面說明一個問題。大標題配小節，更簡潔。
下面的各個章節，也是這個幻燈片文件的主要內容。
當然你如果問題不大，對自己的大腦記憶體以及表達能力有信心，也可以不寫設計文件。 風險自己承擔了，其實設計文件不費時的。
陳述問題
陳述問題，也是陳述需求。
陳述問題，不應該太涉及技術層面的問題。更多是從前使用者的角度來陳述。
陳述問題，應該是普通使用者都能夠看明白是什麼東西。
需要將各種場景都說明白。不能漏掉場景，否則對我們之後的設計會存在偏差。
最終設計完成，需要驗證這些問題、需求都得到滿足了。
這些需求、問題，也需要做一個輕重緩急的判別。因為我們整個設計過程，最終需要做一個開發計劃，要求能最快提交一個最小的可工作版本。 這樣才能做到敏捷。
陳述問題，有時候不僅需要明確做什麼，還要說嗎不做什麼，這是需要明確系統範圍。
如果是多使用者系統，需要羅列參與的使用者角色，以及每個人的希望的獲得功能。
工作原理圖
一圖抵萬言。特別是對於用於溝通的設計文件，文字越少越好。圖形能表達最多的內容。
工作原理圖是一個方案的陳述方式。可以有一張，或者多張。這個是整個設計的中心。
工作原理圖，通常包括系統和外部直接的互動關係圖，以及系統內部的組成結構圖。
這 2 種圖，由方框和連線組成，方框表示模組，連線表示介面。需要標註各個介面和模組的名稱，以及介面呼叫的主要順序。
畫原理圖，不僅僅畫畫，而是真正的設計。裡面蘊含大量思辨，需要我們擬清各種概念。
模組和介面命名，是思辨的體現。名不正則言不順。
圍繞這個原理圖，需要對個模組和介面進行說明，這個組成了所謂的設計正文。
使用者 UI 設計
如果需要使用者參與，需要設計使用者 UI。當然如果是後端應用，需要明確介面。
使用者 UI 往往要比較早明確，因為明確 UI，才能細化需求，這個和概要設計也是相互呼應和印證的。
使用者 UI 設計之所以重要，在於，這是更多從使用者的角度思考問題，因此更能完整表達系統，明確正確的方向，方便引導思考進入深入。
當然如何設計，也會考慮從前方便實現的角度權衡。二者之間如何拿捏，這個是藝術所在。
開發計劃
也就是 todo。
一次設計下來，是需求和想法不斷膨脹的過程，往往把簡單的事情，弄得很複雜。
開發計劃，則是如何幹了。這時候主要的思考點，就是理想很偉大，但是我們如何做快速做一個可工作的最小版本。
大膽假設，小心實踐也是這個意思。其實我們設計的內容，可能很多都是錯的。
設計是永遠的，不會終止於一次設計文件，也不會終止於評審，也不會終止於若干次改稿。 設計在開發的過程中，才是真正深入，這時候會不斷發現之前設計的問題。
做一個最小可工作版本，這時候再次評估一下設計，發現問題多多。
所以，設計要儘早做，因為每一次回顧，我們基本上都會有新思路。 最早設計，最晚動手，這才是靠譜的方法。留給我們更多時間去消化完善設計。
根據問題，補充內容
初步的設計完成，就會發現各種問題，和疏漏。
準確記錄下問題，然後思考解決方法。
其實我們如果能夠準確的表達出問題，解決方法往往是呼之欲出的。
更新 Reference 文件
其實設計文件，長期保留的價值並不大，原因是:
- 文件過於簡單，而且之後各種產品文件應該會包含設計文件的內容。
- 文件很容易過時，正式開始編碼之後，設計仍然在變，這時候通常不會再去更新設計文件
所以設計文件通常都是虎頭蛇尾的。
一旦確定設計，設計人員需要優先更新 Reference 文件，而且長期去維護這個 Renference 文件。
Reference 文件是一些參考手冊，包括 API 手冊、系統維護手冊，諸如此類。
這些文件是提供給其他使用者，需要永久保留的。
很多人老是覺得沒有時間維護這些文件。在設計階段維護這份文件，其實很重要。
這份文件，其實就是詳細設計文件，在編碼之前，從使用者角度更深入的設計系統，再次發現設計的問題。
如果覺得 APi 很奇怪，或者操作手冊很難寫，那麼可能設計存在問題。
小節一下
分析問題、解決問題，我的套路，基本是這些，其實不麻煩。
但是這些是可以用在生活工作的各個方面的，是屬於“道”層面的東西，如果編碼是“術”的話。
我們都希望成為一個做事靠譜的人，即便在你不熟悉的領域，也能借助資源做好一件事情，上面的分析方法，可能值得借鑑。
相關閱讀
評論(4)