技術評審，你拿什麼來吐槽？

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

如今，給你一個機會，來吐槽別人的方案或者代碼，該從何開始？

是否是以爲有千言萬語想要迸發，弄到最後只想起個代碼命名問題？若是你是java，你會想到《粑粑開發規範》，可那仍是代碼層面的。包括把sonar給上了，也是發現一些淺顯的問題。

如今的開發人員參差不齊，爲了將風險儘可能消滅在萌芽中，須要一些手段。其中一種手段就是技術評審，用羣衆雪亮的眼睛，來回頭是岸。

一、技術評審分類

技術評審會擠佔產品開發的時間，但會提升產品的質量、軟件的性能、擁有良好的擴展性、易於重構，長遠來看是澤被後人的事情。

若是對單體的研發能力並不能徹底掌握，那必定要堅持技術的評審，可讓你免去不少無聊低級的故障和缺陷。

但鑑於目前大部分開會抓不住重點的現狀，偏題是常見的。要正確面對技術評審，不要開出火藥味，也不要走過場，這是兩個極端。

對於技術研發，我大致將研發技術評審分爲三類。鑑於篇幅問題，點到爲止。

根據通常軟件的開發過程。大致可分爲：方案評審、設計評審、代碼評審。不少時候，咱們僅僅關注代碼評審，對一些結構問題發現的晚，形成了代碼質量很高但總體質量不好的後果。

二、方案評審

2.一、方案背景

一、闡明方案要解決的問題、危害。

也就是簡單的立項緣由。假如問題不成立，則設計無心義。

二、儘可能一個方案解決一個主要問題。

最後把同一週期的問題串聯，看是否總體最優。所謂先分後總，不可只照顧本身那一塊。

2.二、可落地

一、方案要可以落地，過渡，不能偏離實際，構建一個烏托邦。

要根據公司可協調的資源進行設計。好比，一個不想花大價錢買服務器的公司，並不適合把日誌打印的太詳細，保存的時間過長。

二、代價要儘可能小，可以分步驟進行，可階段性驗收。

對於週期稍長的功能，要有里程碑，以便對外同步和進度追蹤時，可以有章可循。

2.三、是否引入新組件

一、可否利用先有資源完成需求。

理想很豐滿，現實很骨感。好的方案並不必定是業界最優方案。引入一個新組件的成本是很是大的，哪怕它很穩定。

二、新組件的調研和維護。

若是確實須要引入一些組件，要有基本的調研，以及對之後組件維護的考量。

2.四、良好的擴展性

一、方案要有前瞻性，避免短時間內重構。

這個通常看到2-3年就ok了，但要避免短視，不到半年推翻重來的那種。

二、要有良好的擴展性。

擴展性必然會增長模塊的個數和對外接口的數量，要和上面的「可落地」相配合，不能顧此失彼。通常說來，提供可以擴展的接口能力，即表示有不錯的擴展性。

2.五、涉及的組和人

一、研發資源的投入。

對參與人員的能力有較好的把控，不定差距太大的目標，這就要求對任務的拆解要詳細，可以掌握對難點問題的處理。

二、多部門溝通協調。

若是功能涉及到公司的多個部門，對其餘部門的能力和工期考量也要計算在內，主要人員全程參與是必要的。

三、設計評審要點

3.一、提供設計圖

一、須要留下可以被看懂的文檔設計圖。

設計通常會隨着問題的深刻而產生細微的變化，但總體的思路是不會變的。設計圖能夠減小一次次溝通的成本，避免重複性的討論。

二、可以體現設計者的簡單意圖。

設計圖要簡潔，突出主要功能。次要功能能夠輔以附加圖解釋，不可喧賓奪主，忽略了主要業務的評審。

三、遵循已有規範和架構。

任何公司都會有本身的規範和架構，水土不服的設計，註定了將來的坎坷。要在充分了解公司現狀的前提下，進行設計的修正。

四、是否考慮遺留接口處置。

許多開發人員喜歡開發新功能，對待遺留代碼如同臭狗屎。設計階段就須要考慮這些因素，對於遺留接口的適配、擴展、下線問題，表明了將來bug的數量。

五、是否考慮歷史數據處置。

設計方案若是須要修正歷史數據，這個過程就危險的多。你的任意一個字段的刪減、變動，均可能引發很是嚴重的後果。大致的設計原則是隻加不減進行過渡 。

六、是否考慮新舊方案並行、回退。

不少時候，你的新設計須要和舊的功能並行，這種時候，要考慮舊方案的下線影響和週期；若是你的設計是爲了替換舊功能，就要考慮在發生嚴重問題時的回退，這一般可以保命。

3.二、下降複雜性

一、對複雜性進行評估。

通常狀況下，複雜性體如今如下方面：1）調用鏈過長 2）程序策略複雜沒法落地 3）跨庫、跨存儲 4）使用了緩存 6）使用了異步。

以上每個點，大多數狀況下都是能夠進行優化的，也是疑難bug的發生地。邀請幾個對業務熟悉的人，以及對分佈式應用問題敏感的開發人員參與，能夠及早的規避問題。好比，提到緩存，就能想到數據同步、穿透、雪崩、容量等問題，就叫作技術敏感。

針對設計內用到的每一個組件，均可以進行「技術敏感」型評審。

二、裁剪沒必要要組件。

組件如無特殊必要，不要引入，優先借助公司現有設施完成。不能管生無論養。

3.三、驗證方式

一、單元測試設計。

你的設計，可否方便的進行單元測試。若是不能進行單元測試，該如何驗證一些邏輯的正確性。

二、接口測試設計。

你的設計，收否將全部的功能揉在了一塊，牽一髮而動全身，沒法進行接口測試。存在此問題的設計有不少，好比使用未知的json（字符串）進行數據傳輸、一次性傳輸多個冗餘、干擾性數據等。

3.四、高可用（服務）

一、服務分級。

你的設計，以及功能，所處的地位。是否須要更多資源，來保證更高的SLA級別。是否須要彈性部署或者預留資源？是否有不可預料的請求尖峯？

二、上下游影響提醒。

你正在設計的功能，對上下游的影響。對上游，是否能夠作到承諾的服務級別（通常SLA會比上游服務的略高）。對下游，就要考慮是突發流量的發源地：通常來源於定時任務、或者多線程。

3.五、高可靠（數據）

一、數據一致性。

發生極端狀況（好比某些重要組件死亡）後，數據是否會發生不一致。通常的服務降級，都會引發數據的一致性問題。這部分能夠沒有自動化的修復方案，但要對修復的難易程度進行初步評審，若是難度過大，要經過記錄冗餘信息的方式進行解決。

二、模擬演練。

在上線以前，對可能的節點進行模擬演練。可物理演練，也可紙上談兵。

3.六、資源

一、肯定各部門資源。

設計階段肯定詳盡的部門協調資源，肯定整個流程中的短板部門，進行資源傾斜。

二、排期。

按照里程碑對功能進行拆解、排期，此部門要可以達到估計大致工做量的程度。

3.七、風險

一、是否有技術難點？

技術開發一樣存在28原則。幾個技術難點，可能會佔據你80%的時間。這些問題一般會阻塞到最後纔會被解決，你須要找到一個Mock的方式，默認已經打通了這些通道。

二、是否有業務風險？

相關功能是否違反了相關法律法規？是否收集了不應收集的東西？是否某些敏感信息沒有作脫敏處理？若是這些都不是你來確認，那就默默的閉嘴。

三、安全。

某些安全問題要提早預知到，好比惡意註冊、限流、封禁等。若是資源有限，這些一般是優先級比較低的。在成長爲大象以前，可以盯上你的都是螞蟻。

四、代碼評審要點

4.一、自動化代碼審查結果

一、哪一個級別必須處理。

使用sonar初步掃描，可以發現不少問題。這避免了引經據典（特指開發規範）的狀況。自動化的東西總比記在腦子裏的東西更加可信。

4.二、double評審

一、審主要處理邏輯。

二、審異常處置。

三、審性能。

四、審提示信息。

五、審註釋。

以上，是一個優秀的開發者都須要掌握的內容。處理邏輯的正確性，是功能經過驗收的基本，可是出問題的一般是一些比較隱蔽的地方。

一些異常會暴露敏感信息，或者走向了不可預料的分支。一些錯誤提示會顯得不友好，給使用者形成不少困擾。一些註釋信息會偏移實際，尤爲是在開發人員不穩定的狀況下。

此步驟的評審，360度無死角。

End

許多公司，是沒有過剩的能力進行技術評審的，開發人員也如公交車通常上下，這也是時間越久積毒越深的緣故。

不要爲了評審而評審，評審是爲了解決問題的，不是爲了形式。假如你每次都把會開出流水帳通常的感受，全部人都連連點頭（瞌睡），那不是流程有問題，是你在官僚的路上中毒已深。

做者簡介： 小姐姐味道 (xjjdog)，一個不容許程序員走彎路的公衆號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不同的味道。個人我的微信xjjdog0，歡迎添加好友，​進一步交流。​