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