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