設計評審（design review），即在真正開始開發之前，組織一次或多次會議，先評審設計，以降低日後返工甚至專案失敗的風險。相信工作過一段時間，開始主導乙個功能模組甚至整個系統的同學，都對設計評審不會陌生。今天偶然看到了一篇亞馬遜vp及distinguished工程師brad porter的一篇部落格，講述了設計評審容易陷入的問題以及他主張的一些最佳實踐。也許並不適用於所有公司和專案組，但不妨一聽，借鑑其中對自己有用的部分。
先放上英文原文供感興趣的同學閱讀，標題就是：《why design reviews so painful & how fix》，為什麼design review如此痛苦，如何改善它。
典型的設計評審是什麼樣呢？召集一群專案相關人員，主要是經理和工程師們。工程師又主要由比較有經驗的架構師、高階工程師等組成，當然也會有其他工程師旁聽。會議開始後，一般有經驗的工程師會更主動表達自己的想法。這點是可以預料到的，因為他們的寶貴經驗會給予他們多個視角來看到你要解決的問題。但問題是，每個人可能都會有好幾種想法，假設#想法=3，如果5個人發言的話，去掉相近的，可能就產生了10-15種視角。於是設計評審會議就開始失控。最終的結果就是：評審人覺得自己很聰明，表達了很好的觀點，而你最後發現沒有幾條具體的建議可以採納。於是，一次低效的設計評審就結束了。
閱讀時間：即便提前在會議邀請郵件中附上了設計文件，可能也很少有人會仔細看。所以，會議一開始就是大家一起安靜看文件的時間。出於這個原因，至少第一次在會議，大家都不熟悉背景的情況下，設計文件不能過長。作者主張最多6頁，包括附錄。
回答時間：收集完問題後，可以讓大家休息五分鐘，同時設計者你開始思考設計文件中哪一部分可以解答這些問題。等休息結束後，就對這些問題一一解答。這樣每個人都有機會表達自己的觀點，即便之後的討論再次失控，最壞情況下你得到了乙份有價值的問題列表。
QA如何高效參與設計評審
qa如何高效參與設計評審 目標與方法 帶著如果按這個做出來後，真的能實現我們的需求與功能嗎？用各類使用者場景去構想他的設計與實現是否可行，是否存在遺漏。即提前去把所需功能按設計的思路，我們在腦海裡來執行一下 對關鍵的設計決定進行驗證，並幫助關鍵專案從設計階段轉化為最後的實現 從下面幾個方面去評審這份...
現代C 如何高效地設計建構函式
不知道啥是std move 的同學請簡單做一下課前預習。先從乙個我們非常熟悉的情形入手，我們需要寫乙個student類，傳入引數為std string，任何一名上課認真聽講的學生都會想到傳const class student private std string name 讓我們拋開c 11後引入...
如何高效地管理時間
如何高效地管理時間 現代人的生活節奏越來越快，壓力也越來越大。經常會聽到白領人士抱怨乙個星期有三到四天的時間在加班，沒有時間鍛鍊身體，身體經常處在一種透支的狀態 也有人抱怨，雖然現在的職位已經到了中層管理層，但是沒有安全感，因為知識的更新速度太快。其實大家都感覺到時間是個瓶頸，每天列了一大堆的計畫，...