程式設計師如何講清楚技術方案

最近在評審技術方案，和**review的時候，遇到剛入行的同學們，很多都講不清楚技術方案。

具體表現是：

– 上來不說需求，直接說演算法實現。台下一頭霧水，根本不知道設計方案是否合理。

– 描述完需求後，又直接看**，看表結構，沒有交代流程。

– 比較簡單的演算法，描述的特別繞，讓人聽不懂。被別人指出後，覺得這東西這麼簡單，你們為什麼聽不懂，還很委屈。

– 直接說術語，不給解釋。還有自己造術語不給解釋的，更混亂的是「復用」已有的術語，讓大家理解都不同。

那麼程式設計師如何把技術方案講清楚呢？下面從實用的角度教大家一些小技巧，在短時間內具備講清楚的能力。在文末給出通用的方**學習書籍，供長線學習，達到把所有事情都能交代清楚。

為什麼要做這個需求，對於實現的要求是什麼，產品經理提了哪些邊界條件。沒有銀彈，乙個技術方案的好壞與實現要求息息相關，是不能脫鉤的。例如，乙個介面訪問質量統計系統，可以接受一天跑一次指令碼生成資料。但是為使用者提供服務的消費明細，肯定要能實時展示，並且不能出錯。

在評審中，消耗時間比較多的，就是台下的聽眾問被評審人需求背景。還有台下的人給出了某個建議，然後被被評審人否定，說有個產品的要求我剛才沒說。這時對提出建議的人來說，是很傷的。

交代好背景並對齊，是評審技術方案和**review的基礎，否則別人不知道你後面的是否合理，甚至不知道你到底在做什麼。技術方案評審就無從談起了。

背景知識說完後，說你的做法。要先總後分，先從整體介紹架構設計。有哪些模組，各自負責什麼職責，如何銜接……讓大家有個整體認識，看到哪部分是主要矛盾，大家把80%的精力花費在20%的重要模組上評審，好鋼用在刀刃上。

例如乙個發獎活動，最重要的模組是發獎**模組，但是上來不講整體，而是先講展示活動規則的模組，而且用掉了大半的時間，是很浪費人力的。

整體架構的描述用架構圖、流程圖，加上簡練的語言，交代明白即可。一般都有架構模板，直接按照模板的要求，參考已有的優秀例子，都不會有大問題。最重要的是這塊要先講，先交代清楚。

整體方案介紹完之後，介紹協議和資料庫表設計，開始逐步深入細節。因為這塊設計的是否合理，對程式的效率影響比較大。

分清哪些協議、表是重要的，著重講，其他不太重要的快速講。

協議的執行流程，要交代清晰，整個協議是怎麼在各個模組中流轉的，到具體資料修改時，是如何和已有表結構串聯起來的。這也是程式執行的流程，如果講不清楚，會深度懷疑你是否能實現清楚。

這部分要注意，盡量少說術語。因為大家的背景知識不同，一些專門術語大家是不知道的，你要用直白的話語讓大家聽明白。

例如：有人在描述協議流程時說「我呼叫server提供的123號命令，返回成功後，把資料庫的state欄位改為2，就完成發獎了」。但是你說的123是幹什麼的，state是什麼意思，2是什麼狀態？

大家的疑問太多了，好的說法應該是，「我呼叫server提供的123號發獎的協議，返回成功後，把資料庫中該使用者的發獎狀態，更新為已發獎」。

經過前面幾部的講解，方案基本上講完了。剩下的就是講分支邏輯，和異常邏輯。乙份**寫的好不好，程式設計師是否有經驗，主要是看對於異常處理是否到位。

這部分從架構上主要講容災、魯棒性，例如某個server死掉了，或者某個模組頻繁請求，你的系統是否有預警，能夠相容。說白了就是要講解系統的邊界條件和服務能力。

最後上**，如果是**review，在這個時候才開始說你的**。雖然看的時間比較晚，但是大家都知道你的**是什麼功能了，看的速度也會加快。

每次評審後，要自己覆盤，總結。別人都問題哪些問題，為什麼要問？哪些問題是我應該交代沒交代的，讓人家問了？哪些是我方案的問題，別人提出的挑戰？

對於自己沒交代的，思考為什麼會漏，如果能提前講清楚，是否能節約很多時間。

根本的心法就是要有同理心。從對方的角度思考，這個問題他會了解嗎，我不說他明白嗎？方案評審重要的不是你說完，而是別人聽懂。關注台下人的反應，你的任務不是講，而是讓大家聽明白。不是乙個勁的說，而是要讓大家都理解你的意思，這樣別人才能幫你。否則別人會一直問問題，挑戰你，最後否定你的方案。

千萬不要覺得聽眾好笨，這麼簡單都不明白，如果台下的人都不明白，那麼一定是你錯了。能力強的人是能夠把難題講解的很簡單的。美國有專門負責科普的作家，把複雜的科學知識做到「老嫗能解」。台下評審的人都是身經百戰的，如果他們都反映聽不懂，那麼會是誰的問題呢？

技術方案講解要先交代背景，再講整體架構，再細化流程。先主線，再分支，先正確路徑，再異常邏輯。要在聽眾的角度去講，盡量直白簡單，能夠讓不懂技術的人聽懂才是最好的。