最近在評審技術方案，和**review的時候，遇到剛入行的同學們，很多都講不清楚技術方案。
具體表現是：
– 上來不說需求，直接說演算法實現。台下一頭霧水，根本不知道設計方案是否合理。
– 描述完需求後，又直接看**，看表結構，沒有交代流程。
– 比較簡單的演算法，描述的特別繞，讓人聽不懂。被別人指出後，覺得這東西這麼簡單，你們為什麼聽不懂，還很委屈。
– 直接說術語，不給解釋。還有自己造術語不給解釋的，更混亂的是「復用」已有的術語，讓大家理解都不同。
那麼程式設計師如何把技術方案講清楚呢？下面從實用的角度教大家一些小技巧，在短時間內具備講清楚的能力。在文末給出通用的方**學習書籍，供長線學習，達到把所有事情都能交代清楚。
一、要先交代需求背景。
為什麼要做這個需求，對於實現的要求是什麼，產品經理提了哪些邊界條件。沒有銀彈，乙個技術方案的好壞與實現要求息息相關，是不能脫鉤的。例如，乙個介面訪問質量統計系統，可以接受一天跑一次指令碼生成資料。但是為使用者提供服務的消費明細，肯定要能實時展示，並且不能出錯。
在評審中，消耗時間比較多的，就是台下的聽眾問被評審人需求背景。還有台下的人給出了某個建議，然後被被評審人否定，說有個產品的要求我剛才沒說。這時對提出建議的人來說，是很傷的。
交代好背景並對齊，是評審技術方案和**review的基礎，否則別人不知道你後面的是否合理，甚至不知道你到底在做什麼。技術方案評審就無從談起了。
二、介紹技術方案整體架構
背景知識說完後，說你的做法。要先總後分，先從整體介紹架構設計。有哪些模組，各自負責什麼職責，如何銜接……讓大家有個整體認識，看到哪部分是主要矛盾，大家把80%的精力花費在20%的重要模組上評審，好鋼用在刀刃上。
例如乙個發獎活動，最重要的模組是發獎**模組，但是上來不講整體，而是先講展示活動規則的模組，而且用掉了大半的時間，是很浪費人力的。
整體架構的描述用架構圖、流程圖，加上簡練的語言，交代明白即可。一般都有架構模板，直接按照模板的要求，參考已有的優秀例子，都不會有大問題。最重要的是這塊要先講，先交代清楚。
三、介紹協議、庫表設計
整體方案介紹完之後，介紹協議和資料庫表設計，開始逐步深入細節。因為這塊設計的是否合理，對程式的效率影響比較大。
分清哪些協議、表是重要的，著重講，其他不太重要的快速講。
協議的執行流程，要交代清晰，整個協議是怎麼在各個模組中流轉的，到具體資料修改時，是如何和已有表結構串聯起來的。這也是程式執行的流程，如果講不清楚，會深度懷疑你是否能實現清楚。
這部分要注意，盡量少說術語。因為大家的背景知識不同，一些專門術語大家是不知道的，你要用直白的話語讓大家聽明白。
例如：有人在描述協議流程時說「我呼叫server提供的123號命令，返回成功後，把資料庫的state欄位改為2，就完成發獎了」。但是你說的123是幹什麼的，state是什麼意思，2是什麼狀態？
大家的疑問太多了，好的說法應該是，「我呼叫server提供的123號發獎的協議，返回成功後，把資料庫中該使用者的發獎狀態，更新為已發獎」。
四、描述分支和異常邏輯，講解**
經過前面幾部的講解，方案基本上講完了。剩下的就是講分支邏輯，和異常邏輯。乙份**寫的好不好，程式設計師是否有經驗，主要是看對於異常處理是否到位。
這部分從架構上主要講容災、魯棒性，例如某個server死掉了，或者某個模組頻繁請求，你的系統是否有預警，能夠相容。說白了就是要講解系統的邊界條件和服務能力。
最後上**，如果是**review，在這個時候才開始說你的**。雖然看的時間比較晚，但是大家都知道你的**是什麼功能了，看的速度也會加快。
五、覆盤
每次評審後，要自己覆盤，總結。別人都問題哪些問題，為什麼要問？哪些問題是我應該交代沒交代的，讓人家問了？哪些是我方案的問題，別人提出的挑戰？
對於自己沒交代的，思考為什麼會漏，如果能提前講清楚，是否能節約很多時間。
根本的心法就是要有同理心。從對方的角度思考，這個問題他會了解嗎，我不說他明白嗎？方案評審重要的不是你說完，而是別人聽懂。關注台下人的反應，你的任務不是講，而是讓大家聽明白。不是乙個勁的說，而是要讓大家都理解你的意思，這樣別人才能幫你。否則別人會一直問問題，挑戰你，最後否定你的方案。
千萬不要覺得聽眾好笨，這麼簡單都不明白，如果台下的人都不明白，那麼一定是你錯了。能力強的人是能夠把難題講解的很簡單的。美國有專門負責科普的作家，把複雜的科學知識做到「老嫗能解」。台下評審的人都是身經百戰的，如果他們都反映聽不懂，那麼會是誰的問題呢？
技術方案講解要先交代背景，再講整體架構，再細化流程。先主線，再分支，先正確路徑，再異常邏輯。要在聽眾的角度去講，盡量直白簡單，能夠讓不懂技術的人聽懂才是最好的。
延伸閱讀
通用的方**可以學習《金字塔原理》《問題的分析與解決》中的scqa、mece等方法，這些才是根本，要努力學習和刻意練習才能夠掌握。
程式設計師如何講清楚技術方案
程式設計師如何講清楚技術方案
最近在評審技術方案，和 review的時候，遇到剛入行的同學們，很多都講不清楚技術方案。具體表現是 上來不說需求，直接說演算法實現。台下一頭霧水，根本不知道設計方案是否合理。描述完需求後，又直接看 看表結構，沒有交代流程。比較簡單的演算法，描述的特別繞，讓人聽不懂。被別人指出後，覺得這東西這麼簡單，...
程式設計師如何講清楚技術方案
最近在評審技術方案，和 review的時候，遇到剛入行的同學們，很多都講不清楚技術方案。具體表現是 上來不說需求，直接說演算法實現。台下一頭霧水，根本不知道設計方案是否合理。描述完需求後，又直接看 看表結構，沒有交代流程。比較簡單的演算法，描述的特別繞，讓人聽不懂。被別人指出後，覺得這東西這麼簡單，...
如何講清楚async和await？
async和await要搭配promise使用,它進一步極大的改進了promise的寫法 來看乙個簡單的場景 假設有4個非同步方法要按順序呼叫 newpromise function resolve then function then function then function 語法上不夠簡潔,...