對一次架構設計的總結和反思
最近做了一次架構（流程）的設計，簡單來說，是設計一個流程，提供相應的API，方便其他程式員將業務邏輯逐步遷移到另一套框架。在完成這次設計的過程中，還是有許多經驗、教訓，值得思考和記錄。其實，這些經驗總結，可能在其他地方看到過，也聽別人分享過，不過只是“夫子言之,於我心有慼慼焉”，只有當自己親身經歷過，才會更加深刻。
本文地址： ofollow,noindex">https://www.cnblogs.com/xybaby/p/9763030.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，即使只是打一個日誌。
在一個複雜的流程系統中，狀態的自愈非常重要，這樣即使出現一些異常，也能正常工作
總結了感觸最深的幾點，不是很系統。