關(guān)于開發(fā)流程的建議

縱觀互聯(lián)網(wǎng)家項目的整個開發(fā)流程掺喻，可以簡單梳理為：設(shè)計->需求澄清->開發(fā) ->測試->上線着绷。這個也是普遍的開發(fā)流程蛔钙，但是需要關(guān)注的是，互聯(lián)網(wǎng)家的測試是黑盒測試蓬戚。黑盒測試也稱功能測試夸楣，它是通過測試來檢測每個功能是否都能正常使用。在測試中子漩，把程序看作一個不能打開的黑盒子豫喧，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進行測試幢泼，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用紧显，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。所以它并不是基于代碼的測試缕棵。

那么黑盒測試會逐漸暴露出一個什么問題呢孵班？黑盒測試不可能覆蓋所有代碼涉兽，覆蓋率較低，大概只能達到總代碼量的百分之30篙程，特定的程序代碼無法被測試到枷畏，舉個例子，程序的入庫邏輯虱饿，更新或者插入某張表拥诡，那么入庫邏輯是不會被測試的。再舉個例子氮发，程序的錯誤的校驗邏輯也可能測試不出來渴肉，畢竟黑盒測試只關(guān)注輸入與輸出。

但是進行白盒測試昂貴的爽冕，所以為了彌補黑盒測試帶來的缺陷仇祭，我建議可以在開發(fā)流程中增加代碼評審環(huán)節(jié)。

代碼評審就是我們所說的Code Review,通常多人協(xié)助開發(fā)下颈畸，為了提高主庫代碼的質(zhì)量乌奇，保證良好的軟件架構(gòu)，促進團隊的知識共享承冰，提高團隊整體水平华弓，代碼評審這一環(huán)節(jié)就顯得尤為重要。

代碼評審的目的

根據(jù)Google 工程團隊執(zhí)行代碼評審活動后發(fā)現(xiàn)困乒，除了捕捉bug外寂屏，還對5大無形收益。

· 代碼評審促進團隊和個人開放度

· 代碼評審提升團隊交付標準

· 代碼評審激勵團隊協(xié)作

· 代碼評審保持安全至上

· 代碼評審構(gòu)建社會認可

什么時候進行代碼評審

代碼評審最重要的一點是非常靈活娜搂，無固定形式迁霎，隨時隨地都可以發(fā)起的。根據(jù)github跟apache的一些開源項目的代碼評審實踐百宇，往往是將PR合并到主干時進行評審并作為是否合并到master分支的一個準入條件考廉。那么針對互聯(lián)網(wǎng)家項目組，可以在合并到dev分支之前携御，也就是轉(zhuǎn)測之前進行一次代碼評審昌粤，評審作為是否能合并到master分支的一個準入條件。

如何執(zhí)行評審

前期準備工作：

提前安排好一個小的房間或者會議室啄刹，利用投影儀和gitlab涮坐，進行Code Review，評審會議的成員為組內(nèi)的相關(guān)同事誓军，組長或者項目模塊負責人袱讹，產(chǎn)品經(jīng)理，項目經(jīng)理等昵时，成員可以靈活安排捷雕，最好三個以上椒丧。

代碼作者：

· 確定待評審代碼的范圍

根據(jù)SamrtBear在思科的一個系統(tǒng)小組的研究，一個開發(fā)人員一次評審的代碼在200-400之間救巷，審查超過400行代碼后效率和發(fā)現(xiàn)均呈下降趨勢壶熏。如下圖： [圖片上傳失敗...(image-95a738-1568186532925)]

同時，一個小時審查的代碼行數(shù)應該少于500行浦译，超過500行后效率呈下降趨勢久橙。 [圖片上傳失敗...(image-ce0b9d-1568186532925)]

· 簡單描述代碼的業(yè)務(wù)邏輯以及主要的業(yè)務(wù)流程

· 開放的心態(tài)接受評審的問題跟建議

代碼評審者：

· 準備一個檢查列表（checklist）,把檢查出來的問題標記出來。

· 了解業(yè)務(wù)邏輯和主要流程管怠。

· 準備好一些問題，對于不確定或者不明白缸榄，盡量以問題形式跟作者溝通渤弛，而非質(zhì)疑。

· 準備一些解決方案甚带。在提出問題時候她肯，同時思考更好的方法或者解決方案是什么？你的方法好在什么地方鹰贵？

代碼評審的關(guān)注點：

· 功能性 - 功能完整晴氨，是否嚴格按照產(chǎn)品說明書實現(xiàn)產(chǎn)品的所需的功能點

· 可讀性 - 代碼易讀易懂，其它人能夠輕松從代碼中讀邏輯和設(shè)計思想碉输，命名是一個學問籽前。

· 可測性 - 代碼能夠輕松被單元測試覆蓋，一般來說無法被單元測試覆蓋的代碼不是一個好代碼

· 可維護性 - 代碼運行期間日志輸出完整敷钾，運維人員或者其它人員可以從日志中了解應用的運行邏輯和狀態(tài)枝哄。

· 性能 - 天下武功唯快不破，確保代碼在可度量的數(shù)據(jù)量級下面保持一個穩(wěn)定的性能表現(xiàn)阻荒。代碼是否存在性能問題挠锥，預計峰值流量能到多少。

· 多線程侨赡，并發(fā)和鎖 - 在并發(fā)或者多線程情況下蓖租，代碼執(zhí)行結(jié)果是否有問題。過去幾個月中我們有一個應用是以Shell的方式啟動任務(wù)羊壹，每一個作業(yè)一個進程蓖宦。由于這種方式帶來的資源利用率較低，打算改成多個作業(yè)運行在一個進程中（容器)以節(jié)省系統(tǒng)資源, 上線后發(fā)在存在多處線程不安全的問題舶掖，實例變量被污染導致線上問題球昨。

· 安全性 目前雖然有很多的掃描工具可以幫助發(fā)現(xiàn)代碼安全的問題，但更專業(yè)的開發(fā)人員在寫代碼就已經(jīng)注意這個問題眨攘，避免基本的SQL注入主慰，XSS跨域等問題嚣州。有興趣的同學可以參考OWASP CODE REVIEW GUIDE

代碼評審中注意事項：

· 代碼評審不僅是技術(shù)，也社會學共螺。雙方溝通表達能力決定代碼評審的效率和有效性该肴。評審者需要注意問題的方式或者語氣，就事論事藐不，不上升到精神和思想層面匀哄。而作者則需秉承一切問題都可探討或有更好的方案的想法吸收理解他人的想法，即使評審提出不合適的問題雏蛮，那么你讓隊友知道一個正確的方法仍然是團隊和組織的收獲涎嚼。

· 代碼評審不應太過于關(guān)注代碼風格，代碼風格的檢查完全可以通過IDE或者掃描工具SONARCube集成CheckStyle, PMD挑秉，F(xiàn)INDBUG實現(xiàn)法梯。