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