昨天項目組進行了一個設計評審，主要是對OpenExpressApp的AutoUI部分進行重構，我相當于評審人。大家也可以把這個評審過程當做與人交流你的設計思路的一個過程，以下從我評審的一些要素來談談與人交流設計思路時需要考慮的內容，也許對大家在實際工作中的架構、設計和溝通都有所幫助。

　　評審并不是審判，你直接說出結果之后，然后等著判官下筆，評審一定是基于特定主題進行的，所討論的東西都圍繞這個主題，那么如何讓人先清晰你的這個主題是需要考慮的。對于不同人來說，每個人關注視角不一樣，所以還需要針對這個主題，對于不同場合、不同參與者，你需要使用什么方式來講哪些內容才能夠讓參與者都清晰。

影響我評審關注的一些觀點

• 技術是為業務服務的，再考慮技術時一定需要想想為實際業務做了什么
• 你清楚的別人不一定清楚
  一般自己做的設計會覺得很簡單，可維護很好，但是沒有做過的人理解起來很可能是相反的
• 你覺得簡單的別人不一定覺得簡單
  就拿自己來說，我以前看些書覺得非常難，過了兩三年后，再看之后發現這些書就像入門書一樣。自己不同時期對難易理解不一樣，更何況對于不同人來說呢
• 你對問題的理解不一定是對的
  每個人對問題的深度挖掘能力是不一樣的，有的人只看到表象，而有的人喜歡探索真正的問題，對問題的理解不一樣會導致后續交流評審的內容完全不一樣
• 你的比選方案選考慮因素不一定全面的
  即使問題理解都一致，由于每個人的經驗是不一樣的，你的比選方案不一定是全面的
• 你的具體方案并不一定是最好的
  即使你決定了具體方案，但也不一定是最好的，可能還可以在這個方案基礎上再優化一些內容
• 評審也是溝通的過程
  如何結構化的、從上往下或者從下往上、分塊的闡述你的問題和設計？不要再還未了結需要討論的內容以及必要性之前就直接進入細節，否則大家此時的溝通頻道并不是在一個臺

我的一些提問

• 問題是否正確？
  • 由于是重構，所以我希望一開始看到的是羅列出來的現存的一些問題。
  • 對這些問題，我們可以通過一句話的簡單描述就都清楚，要是太長了估計就是多個問題。
  • 把多個問題放在一起同時講會導致溝通不暢。
  • 對問題的正確性進行討論
• 問題的深層原因？
  • 問題描述清晰之后，我就會問為什么會出現這個問題？
  • 是純技術問題還是業務問題？如果是業務問題，必須拿出現有的實際例子來描述這個問題；如果是技術問題，就需要從質量屬性去描述。
  • 如果是有論據的一定拿出論據，如果是假想的一定說出是有待驗證的
  • 對深層次原因進行討論
• 針對各個問題，逐個從上往下進行分析討論？
  • 總體講完之后，我不喜歡跳躍式的逐層闡述每個問題，我更希望依次討論完每個具體問題
  • 針對具體問題你是如何思考的？
• 對問題的解決方案有哪些？
  • 你是否有考慮過多個方案？
  • 每種方案有何優缺點？
  • 為何選擇當前這種方案
• 開發人員如何使用你的框架？
  • 對于做平臺和框架的人來說，這個問題是必須問題。
  • 如果是基于模型驅動開發的，還需要考慮你的框架是否可以支持模型驅動開發？
• 下一步的粗略計劃？
  • 優先級也是需要考慮的，特別是項目組中馬上就開開發的情況下
  • 可能你的方案需要幾周或者更長時間，接下來三天你會做什么？接下來一周你會做什么？