業務系統升級改造——從小木船到航空母艦

「重構，一言以蔽之，就是在不改變外部行爲的前提下，有條不紊地改善代碼」。《重構——改善既有代碼的設計》一書已經很充分的介紹瞭如何作重構。若是咱們只須要對一小段流程、一小部分代碼作重構，這本書已經提供了很是實用的工具。不過，若是咱們要對整個系統作一個全面的升級改造，書中的技巧就有些「一葉障目不見泰山」了。

並且，技術升級其實並不難。首先，大多數狀況下，技術方案都是比較通用的：你也用SpringCloud，我也用SpringCloud，我倆的方案即便不是如出一轍，相去也不過毫釐之間。其次，技術升級通常會採用開發人員比較瞭解和掌握的技術，這樣設計、實施起來會比較駕輕就熟。所以，這類升級這裏很少說。

可是業務升級卻偏偏相反。首先，與通用的技術方案不一樣，業務邏輯就如孫悟空通常，一樣的業務能夠變化出七十二種不一樣的方案來。例如，同是帳務系統的記帳業務，就可能有單邊帳、雙邊帳、會計科目帳等不一樣的記錄方法，帳務系統A的設計方案與帳務系統B的設計方案也許就是水火不容的。其次，開發人員對業務的瞭解和掌握程度，既不像對技術那樣深刻，也不像產品或業務人員那樣熟悉。所以，由開發人員來升級業務系統，很有點強人所難了。

儘管更加困難，業務升級有時比技術升級更加迫在眉睫。不少業務系統從立項伊始就伴隨着業務的「野蠻生長」，於是不得不採起瘋狂堆代碼、先上線再說這樣飲鴆止渴的策略。遵循這種策略開發出的代碼，很快就會陷入高度冗餘、高度耦合的泥潭中，並由此致使業務邏輯不清晰、改一個需求動一萬行代碼、每天加班需求仍是搞不完、好不容易上線了卻bug不斷等種種問題。雪上加霜的是，因爲陷入其中沒法自拔，開發人員既沒有精力去提升自身技術水平，也很難忙裏偷閒來對系統作技術升級。況且，應對這些問題時，技術升級並非對症的良方：因爲對整個系統的理解上一葉障目不見泰山、或者改造時牽一髮而動全身，技術升級每每只能獲得局部最優解而非全局最優解。就更不要說技術升級有時還要依賴業務升級的成果了。

不知道算幸運仍是算不幸