儘可能讓一切變得簡單，用最簡單的方式完成工作 能用最少的概念，最精簡易懂的概念模型來抽象系統，多一個概念就多一份別人瞭解系統以及維護系統的複雜度，別人也會質疑多一個概念的意義所在，自己如果沒想清楚就容易被diss。 特別是在類的設計中，會發現其實很多時候用一個類就可以表達要乾的單一職責了，每個類職責 ...
儘可能讓一切變得簡單，用最簡單的方式完成工作
能用最少的概念，最精簡易懂的概念模型來抽象系統，多一個概念就多一份別人瞭解系統以及維護系統的複雜度，別人也會質疑多一個概念的意義所在，自己如果沒想清楚就容易被diss。
特別是在類的設計中，會發現其實很多時候用一個類就可以表達要乾的單一職責了，每個類職責清晰，類於類之間關係易於理解及維護。
設計系統時某些功能只在需要它時構建
對於這點深有體會， 特別是在對設計此類系統沒有業務經驗的時候，不要嘗試第一次就構建一個所謂“完美”系統，系統是要面向迭代的，永遠都是隨時準備修改或增加功能，所以設計系統的目標不在於追求一次性構建完美全面的功能，而在於追求系統對功能支持的擴展性，是否能具有快速cover新業務需求，從而分秒迭代自身的能力。
並且業務是多變的，設計時滿足好當前的功能需求，並預留擴展點，即使目前功能不完備，也能在未來快速構建它。
沒必要過度設計，特別是在自身經驗不豐富的情況下，意淫的美好都是太自我，雖然多思考敢於嘗試是好事情，但還是要找高手明確好要做的事情，否則對開發人力的浪費。開發暫時不需要的功能會導致最“重要且緊急”的需求delay或bug風險
敏捷迭代思維
先學會爬，然後再學會走，最後學會跑。換句話說，先保證能夠正常運行，然後優化它使其更好，最後逐漸讓它變得完美。為每個功能制定一個開發周期（最多2周），然後不斷迭代。
註重投資回報率
工作中會發現任務都是排著隊的，至於任務隊列的 compare方法怎麼寫，對於事情的四象限法則，事情的投資回報率是評估是否重要的重要考量。
功能的設計和測試儘可能獨立。如果在設計時考慮到這一點，長遠來看，它將省去很多麻煩，否則只有一切構建完成時你才可以開始測試整個系統。很多時候直到要測試某個功能的時候，才發現代碼相互依賴，而無法獨立測試某模塊。
推行MVP（最小可行產品）
該理念的核心在於：先制定一些用例，完成用例所涉及的相關功能，立即發佈產品，然後根據反饋和經驗對產品進行優化。
在需求評審階段儘可能明確要做的事情，知悉pm需求的業務意義，才能更好更明確的帶著目標做事情，技術評審階段，儘量想清楚需求邊界及所需的技術和業務資源來評估好開發時間，並乘以一個繫數作為交付時間（主要是為後期突然插入的事情留buffer），從項目生命周期開始，直到上線期間，和相關人員經常進行 關鍵步驟同步和確認，大家不會天天盯著你在做的事情，要主動同步進度，尋求反饋，可以避免方向走偏，同時方便對於領導也能掌控全局信息。
在多人協作過程中，流程規範化的意義，比如結論文檔化，分支管理按照契約。大家都有了common sense，辦公效率也是極大提高。
試想微服務系統節點較少，倆人協作的時候，信息的溝通等價於最簡單的的Pub／Sub模型，信息的傳遞較為簡單，大家都會把對方同步給自己的事情處理好，甚至還閑著沒事兒催促你好幾遍，因為每個人只訂閱對方的消息，來源單一，處理起來不會遺忘。後來的後來系統複雜了（同事多了），你作為生產者有了好多個消費者同事，比如你要改一個介面，涉及到好幾個其他模塊開發者，你推動這次升級需要每階段都push各方同事這時候有個問題：
除了其它端，發現 支付端 也需要升級你的介面，然後屁顛屁顛跑人家那又巴拉巴拉描述如何升級——每個消費者接入，都需要生產者開發適配新消費者的消息發送代碼。
學會解耦
別忘了工作中你本身作為生產者同時也在訂閱別人，總之你作為一個節點，你的所有peer消息你都要處理，消息量大還處理不過來，容易遺漏。要麼是push消息，要麼是處理別人的消息，對於push別人的消息，你還要做好“降級”，因為你告訴別人這樣做了，你確保不了別人一定按你說的做，消息一多這個時候人腦子會很容易亂的，別人如果做錯了，如果不承認你給他push過消息怎麼辦？你要背鍋嘛。。。
怎麼辦呢？ 引入業務消息中間件～
所以人多了就得學會解耦，每個模塊都有人專門負責，模塊間的溝通工作，需要一種協議來確保溝通準確性和解耦，上面說的是典型的同步rpc協議，意味著你要瞭解所有的消費者，還要處理新來的消費者，沒有消息落盤，不可追溯。如果這個時候有一些文檔或消息群來承載結論性的消息變更，大家都只需要跟蹤這個文檔或這個群就可以了，生產者就往裡push消息，剩下的分散式消息處理一致性讓別人來保證就可以了，哪一端沒處理好，怪不了你了可。
首先不用處理對別方的降級，都按文檔約定的來的，也同步給你了，對於新的消費者接入，看文檔就好了。 每個人就只需要push消息到文檔落盤，訂閱別人的文檔watch變更，大量消息落盤，個人可以非同步消費，而不會丟消息，落盤的消息可重覆消費，可記錄歷史，避免溝通的扯皮，確保研發環節的有條不紊。當系統更大的時候，每個人工作消息模式複雜度保持不變，這也是 消息中間件 消息消峰 解耦的意義。
還沒關註我的公眾號？
- 掃文末二維碼關註公眾號【小強的進階之路】可領取如下:
- 學習資料： 1T視頻教程：涵蓋Javaweb前後端教學視頻、機器學習/人工智慧教學視頻、Linux系統教程視頻、雅思考試視頻教程；
- 100多本書：包含C/C++、Java、Python三門編程語言的經典必看圖書、LeetCode題解大全；
- 軟體工具：幾乎包括你在編程道路上的可能會用到的大部分軟體；
- 項目源碼：20個JavaWeb項目源碼。
