程序員如何講清楚技術方案

轉載請註明來源：程序員如何講清楚技術方案

本文連接地址：https://www.owenzhang.net/blog/201.html

 

公衆號二維碼：

 

 

最近在評審技術方案，和代碼review的時候，遇到剛入行的同窗們，不少都講不清楚技術方案。

具體表現是：

• 上來不說需求，直接說算法實現。臺下一頭霧水，根本不知道設計方案是否合理。
• 描述完需求後，又直接看代碼，看錶結構，沒有交代流程。
• 比較簡單的算法，描述的特別繞，讓人聽不懂。被別人指出後，以爲這東西這麼簡單，大家爲何聽不懂，還很委屈。
• 直接說術語，不給解釋。還有本身造術語不給解釋的，更混亂的是「複用」已有的術語，讓你們理解都不一樣。

那麼程序員如何把技術方案講清楚呢？下面從實用的角度教你們一些小技巧，在短期內具有講清楚的能力。在文末給出通用的方法論學習書籍，供長線學習，達到把全部事情都能交代清楚。

1、要先交代需求背景

爲何要作這個需求，對於實現的要求是什麼，產品經理提了哪些邊界條件。沒有銀彈，一個技術方案的好壞與實現要求息息相關，是不能脫鉤的。例如，一個接口訪問質量統計系統，能夠接受一天跑一次腳本生成數據。可是爲用戶提供服務的消費明細，確定要能實時展現，而且不能出錯。

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

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

2、介紹技術方案總體架構

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

例如一個發獎活動，最重要的模塊是發獎抽獎模塊，可是上來不講總體，而是先講展現活動規則的模塊，並且用掉了大半的時間，是很浪費人力的。

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

3、介紹協議、庫表設計

總體方案介紹完以後，介紹協議和數據庫表設計，開始逐步深刻細節。由於這塊設計的是否合理，對程序的效率影響比較大。

分清哪些協議、表是重要的，着重講，其餘不過重要的快速講。

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

這部分要注意，儘可能少說術語。由於你們的背景知識不一樣，一些專門術語你們是不知道的，你要用直白的話語讓你們聽明白。

例如：有人在描述協議流程時說「我調用server提供的123號命令，返回成功後，把數據庫的state字段改成2，就完成發獎了」。可是你說的123是幹什麼的，state是什麼意思，2是什麼狀態？

你們的疑問太多了，好的說法應該是，「我調用server提供的123號發獎的協議，返回成功後，把數據庫中該用戶的發獎狀態，更新爲已發獎」。

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

通過前面幾部的講解，方案基本上講完了。剩下的就是講分支邏輯，和異常邏輯。一份代碼寫的好很差，程序員是否有經驗，主要是看對於異常處理是否到位。

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

最後上代碼，若是是代碼review，在這個時候纔開始說你的代碼。雖然看的時間比較晚，可是你們都知道你的代碼是什麼功能了，看的速度也會加快。

5、覆盤

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

對於本身沒交代的，思考爲何會漏，若是能提早講清楚，是否能節約不少時間。

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

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

總結

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

---

延伸閱讀
通用的方法論能夠學習《金字塔原理》《問題的分析與解決》中的SCQA、MECE等方法，這些纔是根本，要努力學習和刻意練習纔可以掌握。

---

轉載請註明來源：程序員如何講清楚技術方案

本文連接地址：https://www.owenzhang.net/blog/201.html