最近在評(píng)審技術(shù)方案，和代碼review的時(shí)候，遇到剛?cè)胄械耐瑢W(xué)們，很多都講不清楚技術(shù)方案。

具體表現(xiàn)是：

上來不說需求，直接說算法實(shí)現(xiàn)。臺(tái)下一頭霧水，根本不知道設(shè)計(jì)方案是否合理。

描述完需求后，又直接看代碼，看表結(jié)構(gòu)，沒有交代流程。

比較簡單的算法，描述的特別繞，讓人聽不懂。被別人指出后，覺得這東西這么簡單，你們?yōu)槭裁绰牪欢€很委屈。

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

那么程序員如何把技術(shù)方案講清楚呢？下面從實(shí)用的角度教大家一些小技巧，在短時(shí)間內(nèi)具備講清楚的能力。在文末給出通用的方法論學(xué)習(xí)書籍，供長線學(xué)習(xí)，達(dá)到把所有事情都能交代清楚。

一、要先交代需求背景

為什么要做這個(gè)需求，對(duì)于實(shí)現(xiàn)的要求是什么，產(chǎn)品經(jīng)理提了哪些邊界條件。沒有銀彈，一個(gè)技術(shù)方案的好壞與實(shí)現(xiàn)要求息息相關(guān)，是不能脫鉤的。例如，一個(gè)接口訪問質(zhì)量統(tǒng)計(jì)系統(tǒng)，可以接受一天跑一次腳本生成數(shù)據(jù)。但是為用戶提供服務(wù)的消費(fèi)明細(xì)，肯定要能實(shí)時(shí)展示，并且不能出錯(cuò)。

在評(píng)審中，消耗時(shí)間比較多的，就是臺(tái)下的聽眾問被評(píng)審人需求背景。還有臺(tái)下的人給出了某個(gè)建議，然后被被評(píng)審人否定，說有個(gè)產(chǎn)品的要求我剛才沒說。這時(shí)對(duì)提出建議的人來說，是很傷的。

交代好背景并對(duì)齊，是評(píng)審技術(shù)方案和代碼review的基礎(chǔ)，否則別人不知道你后面的是否合理，甚至不知道你到底在做什么。技術(shù)方案評(píng)審就無從談起了。

二、介紹技術(shù)方案整體架構(gòu)

背景知識(shí)說完后，說你的做法。要先總后分，先從整體介紹架構(gòu)設(shè)計(jì)。有哪些模塊，各自負(fù)責(zé)什么職責(zé)，如何銜接……讓大家有個(gè)整體認(rèn)識(shí)，看到哪部分是主要矛盾，大家把80%的精力花費(fèi)在20%的重要模塊上評(píng)審，好鋼用在刀刃上。

例如一個(gè)發(fā)獎(jiǎng)活動(dòng)，最重要的模塊是發(fā)獎(jiǎng)抽獎(jiǎng)模塊，但是上來不講整體，而是先講展示活動(dòng)規(guī)則的模塊，而且用掉了大半的時(shí)間，是很浪費(fèi)人力的。

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

三、介紹協(xié)議、庫表設(shè)計(jì)

整體方案介紹完之后，介紹協(xié)議和數(shù)據(jù)庫表設(shè)計(jì)，開始逐步深入細(xì)節(jié)。因?yàn)檫@塊設(shè)計(jì)的是否合理，對(duì)程序的效率影響比較大。

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

協(xié)議的執(zhí)行流程，要交代清晰，整個(gè)協(xié)議是怎么在各個(gè)模塊中流轉(zhuǎn)的，到具體數(shù)據(jù)修改時(shí)，是如何和已有表結(jié)構(gòu)串聯(lián)起來的。這也是程序執(zhí)行的流程，如果講不清楚，會(huì)深度懷疑你是否能實(shí)現(xiàn)清楚。

這部分要注意，盡量少說術(shù)語。因?yàn)榇蠹业谋尘爸R(shí)不同，一些專門術(shù)語大家是不知道的，你要用直白的話語讓大家聽明白。

例如：有人在描述協(xié)議流程時(shí)說「我調(diào)用server提供的123號(hào)命令，返回成功后，把數(shù)據(jù)庫的state字段改為2，就完成發(fā)獎(jiǎng)了」。但是你說的123是干什么的，state是什么意思，2是什么狀態(tài)？

大家的疑問太多了，好的說法應(yīng)該是，「我調(diào)用server提供的123號(hào)發(fā)獎(jiǎng)的協(xié)議，返回成功后，把數(shù)據(jù)庫中該用戶的發(fā)獎(jiǎng)狀態(tài)，更新為已發(fā)獎(jiǎng)」。

四、描述分支和異常邏輯，講解代碼

經(jīng)過前面幾部的講解，方案基本上講完了。剩下的就是講分支邏輯，和異常邏輯。一份代碼寫的好不好，程序員是否有經(jīng)驗(yàn)，主要是看對(duì)于異常處理是否到位。

這部分從架構(gòu)上主要講容災(zāi)、魯棒性，例如某個(gè)server死掉了，或者某個(gè)模塊頻繁請(qǐng)求，你的系統(tǒng)是否有預(yù)警，能夠兼容。說白了就是要講解系統(tǒng)的邊界條件和服務(wù)能力。

最后上代碼，如果是代碼review，在這個(gè)時(shí)候才開始說你的代碼。雖然看的時(shí)間比較晚，但是大家都知道你的代碼是什么功能了，看的速度也會(huì)加快。

五、復(fù)盤

每次評(píng)審后，要自己復(fù)盤，總結(jié)。別人都問題哪些問題，為什么要問？哪些問題是我應(yīng)該交代沒交代的，讓人家問了？哪些是我方案的問題，別人提出的挑戰(zhàn)？

對(duì)于自己沒交代的，思考為什么會(huì)漏，如果能提前講清楚，是否能節(jié)約很多時(shí)間。

根本的心法就是要有同理心。從對(duì)方的角度思考，這個(gè)問題他會(huì)了解嗎，我不說他明白嗎？方案評(píng)審重要的不是你說完，而是別人聽懂。關(guān)注臺(tái)下人的反應(yīng)，你的任務(wù)不是講，而是讓大家聽明白。不是一個(gè)勁的說，而是要讓大家都理解你的意思，這樣別人才能幫你。否則別人會(huì)一直問問題，挑戰(zhàn)你，最后否定你的方案。

千萬不要覺得聽眾好笨，這么簡單都不明白，如果臺(tái)下的人都不明白，那么一定是你錯(cuò)了。能力強(qiáng)的人是能夠把難題講解的很簡單的。美國有專門負(fù)責(zé)科普的作家，把復(fù)雜的科學(xué)知識(shí)做到「老嫗?zāi)芙狻埂Ｅ_(tái)下評(píng)審的人都是身經(jīng)百戰(zhàn)的，如果他們都反映聽不懂，那么會(huì)是誰的問題呢？

總結(jié)

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