131 1300 0010
行業(yè)動態(tài)
當(dāng)前位置: 首頁>> 新聞中心>>行業(yè)動態(tài)>>
  • 導(dǎo)航欄目
  • 產(chǎn)品新聞
  • 企業(yè)新聞
  • 行業(yè)動態(tài)
  • 程序員怎樣講清楚技術(shù)方案
    程序員怎樣講清楚技術(shù)方案
  • 程序員怎樣講清楚技術(shù)方案
  •   發(fā)布日期: 2019-01-03  瀏覽次數(shù): 856

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

    具體表現(xiàn)是:

     

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

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

    程序員怎樣講清楚技術(shù)方案

    比較簡單的算法,描述的特別繞,讓人聽不懂。被別人指出后,覺得這東西這么簡單,你們?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)芙狻?。臺下評審的人都是身經(jīng)百戰(zhàn)的,如果他們都反映聽不懂,那么會是誰的問題呢?

    總結(jié)

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


  • ·上一篇:
    ·下一篇:
  • 其他關(guān)聯(lián)資訊
    深圳市日月辰科技有限公司
    地址:深圳市寶安區(qū)松崗鎮(zhèn)潭頭第二工業(yè)城A區(qū)27棟3樓
    電話:0755-2955 6626
    傳真:0755-2978 1585
    手機:131 1300 0010
    郵箱:hu@szryc.com

    深圳市日月辰科技有限公司 版權(quán)所有:Copyright?2010-2023 www.kqne.cn 電話:13113000010 粵ICP備2021111333號