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