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