業務重構

在重構一個結構繁雜，代碼邏輯千絲萬縷的業務系統時，除了對代碼層面的重構以外，不少人會忽視對於業務結構的重構和簡化。

目前正在遭遇着這個事情，一個異常複雜的系統，不斷的在上面添加需求，代碼量增大，函數的體積也在增加，Web服務也愈來愈臃腫。關於代碼層面的解耦，方法論不少，但本質上就是「提取公因式」，即相同的代碼不要寫兩遍。一般，良好模塊的模塊設計，很容易達成這種只寫一次的目標。

還有的複雜度就是模塊之間的依賴和調用，不少人就會想到，用消息隊列去解耦。其實消息隊列解耦只是在技術層面，把兩個東西物理上分開了，邏輯上仍是要靠消息去驅動，複雜點就變成了什麼時候發消息，發怎麼樣的消息。過於複雜的依賴和調用，在修改的時候，容易出現紕漏，好比漏發了某個消息。

其實我想說的不是技術層面的簡化，而是業務層面的簡化。業務人員首先要捫心自問一下，業務真的有必要設計的那麼複雜嗎？真的須要嗎？若是你以爲須要的話，那你再想一遍，真的須要嗎？

有一些業務人員過分設計，複雜設計，盲目設計，原本簡單的一個業務規則，硬是要設計成很複雜的規則，設計出很複雜的一個功能，可是該功能的使用率很低，可是對於這個功能的維護成本又很大，一不當心出的bug就是由它產生。

理論上，業務設計和程序設計並無區別，無非一個是用天然語言描述，一個用代碼表述。業務設計也是能夠畫出流程圖，狀態圖的。可是，若是一個業務設計天生就複雜，那麼期望代碼層面上很簡潔，很清晰，無異於癡人說夢。

某種程度上說，業務的重構解耦，比代碼層面的重構解耦更有意義。好的業務設計人員，應梳理出各個業務需求，儘可能設計出相互獨立的業務，封裝不變的業務模塊，把噁心的，易變的業務需求單獨切割，儘可能不要影響成熟業務模塊的功能。