對一次架構設計的總結和反思

　　最近作了一次架構（流程）的設計，簡單來講，是設計一個流程，提供相應的API，方便其餘程序員將業務邏輯逐步遷移到另外一套框架。在完成此次設計的過程當中，仍是有許多經驗、教訓，值得思考和記錄。其實，這些經驗總結，可能在其餘地方看到過，也聽別人分享過，不過只是「夫子言之,於我心有慼慼焉」，只有當本身親身經歷過，纔會更加深入。

　　本文地址：http://www.javashuo.com/article/p-mwnfhzwz-kk.html

簡單就是美

　　zen of python中提到 Simple is better than complex.

　　在google bigtable論文中也提到 The most important lesson we learned is the value of simple designs.

　　具體回到此次設計，因爲這些流程都是異步的，且要保證必定的原子性，因此當交互的流程越多，須要維護的狀態也會增多，出問題的機率也越大，這樣在中途失敗的狀況回滾也會更麻煩。在最第一版的設計中，流程圖差很少有一頁A4紙，經過縮減沒必要要的流程，最終方案流程圖不到半頁A4紙，最主要的是，這個流程維護起來更容易，出錯的機率更低。

　　固然，流程的簡化其實會在某些異常狀況下有最終的業務有必定的影響，這其實也是要考慮性價比。

　　奧卡姆剃刀原理：如無必要，勿增實體。

　　

 多跟人討論

　　雖然這個工做主要由我負責，但我發現常常與人討論仍是頗有用的，無論討論的對象是老手、仍是小白。

　　若是是有相關經驗的老手，每每能一針見血的指出問題所在，好比上面提到的流程簡化，就是老手指出來的。若是對方對整個設計比較感興趣，會問一些爲何，這些爲何其實能幫助本身思考，由於不少時候，本身並無思考過爲何。即便對方不太明白我在幹啥，在描述、解釋一個細節的時候也經常會有茅塞頓開的感受，與小黃鴨調試法殊途同歸之妙。

　　

用數聽說話，而不是腦補

　　這一點其實與第一點相關，流程簡化以後，某些狀況下部分用戶會受到影響，這個產品經理的第一反應是不能接受的。但爲了處理這部分異常狀況就會使流程變得複雜，技術這邊以爲性價比低。最後的方案是埋點測試，數據代表會影響的玩家比例很小，PM也就接受了簡化後的流程。

Talk is cheap，show me the DATA!

與使用者溝通，儘早給出可體驗的原型

　　這套流程主要是給項目內的其餘程序使用，剛開始的時候只與核心程序討論，並且是泛泛的討論，致使流程並不徹底符合實際狀況。

　　

接口設計追求One Take

　　接口很重要，一旦交付使用，就很難在修改。

　　這一點是呈上的，因爲開始的流程設計沒法知足某些業務場景，致使須要修改一些API，但前一版本的API已經在代碼中使用，爲了修改這些API，須要去與相應程序溝通，你們集中替換、測試。幸虧這些接口都還在內部系統使用，不涉及到線上業務，不然要修改起來就很困難了。

　　

好的接口 

　　easy to use，hard to misuse，來自 How to Design a Good API and Why it Matters

　　呈上，在流程中，會有一些默認的action，默認的參數，設計的原則是，這些默認值最可能是代碼不能正常工做，而絕對不能默默地以錯誤的方式工做。

流程圖 狀態機幫助思考與討論

　　在此次設計中，常常對着流程圖、狀態機發呆，發現仍是頗有用，能夠幫助理清思路，發現異常。跟他人討論的時候，流程圖也比口頭描述直觀不少。

墨菲定律

　　每一步都要有異常應對，有if 那麼就應該對應 else，即便只是打一個日誌。

　　在一個複雜的流程系統中，狀態的自愈很是重要，這樣即便出現一些異常，也能正常工做

　　

 

　　總結了感觸最深的幾點，不是很系統。