Raffi Krikorian 為“在運行中進行架構重寫”提供了指南

在 O’Reilly軟件架構大會 的開幕致辭中， Raffi Krikorian 為那些承擔了重寫某個系統重任的技術領導與架構師分析了相關的策略與戰術。憑借著他在擔任 推ter工程團隊 的副主裁期間所學到的經驗，Krikorian對于重新設計架構這一流程的管理提出了12點計劃，包括定義“完成”、檢測現有系統，以及維持代碼的質量。

Krikorian 目前是 Uber 高級技術中心的工程領導，之前也在 推ter 工程團隊擔任副主裁，他在致辭中首先 表示 ，重寫、或對某個系統的架構進行重組背后的原因與流程往往會因為一系列問題的出現而備受折磨：人們往往會低估復雜性、人們永遠不會做到完全理解客戶、系統的需求不斷地在改變、而且整個流程所需的時間通常遠遠超出人們的預期。

Krikorian認為，重寫架構的原因通常是由于現有的應用程序無法再滿足客戶的需求、無法實現規模的擴大、或是無法實現類似產品所具有的特 性。在演講中列舉了一系列的系統重寫案例學習、著重指出了一些常見的陷阱，并為承擔一次成功的系統重寫架構任務提供了一些策略。一個核心主題貫穿了整個演 講，那就是盡量避免完整的重寫，但如果已經選擇了走這條路，那么應當事先對以下12點內容進行思考，并在系統重寫架構過程中不斷調整。

1. 堅定方向（為了業務的提高）
2. 定義“完成”
3. 漸進式前進
4. 找到起跑線
5. 不要忽略數據
6. 更好地管理技術債務
7. 遠離那些虛榮的東西（例如使用“熱門”的技術棧）
8. 做好準備面對壓力
9. 了解業務
10. 做好面對政治因素的準備
11. 對于代碼質量有所掌握
12. 讓團隊做好準備

Krikorian隨后依次對這些要點進行了探討，他首先表示，在應用程序的重寫過程中，業務產品經理會表現得非常焦慮，但技術領導必須對這一點加以控 制。業務與技術方面的干系人必須在共同的努力下對什么是“完成”進行定義，這樣才能夠實現一次成功的架構重寫。可以在定義需求時使用一些現有的 需求規格分析 技術，但不應將現有的代碼作為整個新系統的規格說明。

Krikorian同時也表示，要保持新系統與現有系統的功能100%的等價是非常困難的。當現有的系統在生產環境上運行的過程中，有可能會加入新的功能，以應對某些問題或邊界情況，而這些修改也許沒有被很好地記錄在文檔中。

你真的清楚這套系統在做些什么嗎？

“讓新的系統能夠實現現有系統的能力”這一點比你想象中要困難。

大多數程序員甚至都不知道應當問些什么問題，而如果他們并非系統最初的設計者，那他們就更加摸不著頭腦了。

實現特性是一件困難的事，因此更應當采用漸進的方式進行重寫。最合適的方式是采取一種敏捷式的、集成的、并且 基于持續交付 的流程。在每次迭代結束之后，都應當能夠做到隨時準備發布新的系統，并且應該定期地為業務干系人展示經過重寫的功能。Krikorian同時也對在重寫中混入新特性的做法進行了警告：

混入新的特性是相當誘人的行為，尤其是新特性的開發在舊系統中停止的前提下。

但這種做法可能會要了你的命。

在常規的開發中，你也會盡量避免這一點，那么為什么現在又一次犯錯呢？

與應用程序的代碼相比，某個軟件系統底層的數據的變化往往顯得十分緩慢。但Krikorian警告說，在重寫過程中使用虛構的、或是人為的數據會造成安全性方面的錯覺。必須盡快使用真實數據進行測試，有時可以使用類似于 摸黑啟動 （dark launching）或模擬流量（traffic shadowing）之類的技術。必須有計劃地決定如何在現在系統與新的應用程序中保持數據的一致性。對現有系統必須進行全面檢測（包括性能與數據處理兩 方面），然后根據這部分檢測結果在系統重寫中進行決策。

在任何一次系統重寫的過程中，對技術債務的管理都是一個核心部分，如果對這部分視而不漸，會不斷增加軟件的熵。造成技術債務的原因通常是來自于業務的壓力、缺乏流程、缺乏一種定義良好的架構、以及缺乏工程上的導師制度。

Krikorian表示，組織應該培養一種保證設計質量的文化。應當鼓勵重構、同時也應當鼓勵持續設計以及其它有關代碼質量的實踐。在開發時間 中應當專門抽出一部分以解決技術債務。如果沒有合適的照料，那么真實世界中的代碼會變得越來越復雜難懂。由于開發者通常會將更多的時間放在閱讀而不是編寫 代碼上，因此應當通過代碼審查的方式保證代碼結構的“可讀性”。

Krikorian同時也建議，在重寫過程中應當盡量避免“虛榮的東西”，例如選擇某種“熱門”的新語言或技術棧。雖然這種選擇很有誘惑，能夠在短期內提高開發團隊的動力，或將其用做一種招聘工具，但技術領導應當做出對團隊的長期利益有益的選擇。

在重寫的過程中，很有可能會招致客戶的強烈不滿。外部的客戶無法獲得新的特性，而內部的客戶也因為重寫而不得不停下工作。

在整個工程中可能會出現政治性的斗爭，并且由于最后期限幾乎總是被推遲，因此受挫的情緒可能會在在整個組織中蔓延開。

Krikorian警告說，在開始重寫之前“沒有人會考慮到這些問題”。這些斗爭對重寫可能會產生破壞性，而技術領導必須對可能出現的決心動搖的情況進行管理。

在重寫過程中，將一個開發團隊劃分為兩個團隊的做法并不罕見，由其中一個團隊負責維護舊的系統，另一個團隊負責重寫架構的工作。雖然這能夠成為 一種有效的做法，但技術領導需要做好準備，以應對可能出現在這兩個團隊之間的壓力。修復bug與救火是很有壓力的工作，而某一個團隊必須要承擔這一任務， 而另一個團隊則可以置之不理。Krikorian建議，技術領導必須在負責維護現有系統的團隊中維持或建立一種支持的角色。在團隊之間應當定期進行項目進 度方面的溝通，并且保證重寫過程中的所有工作保持透明度。

在重寫開始之前，技術領導要指出所有的業務干系人，這一點十分重要。同時也要指出在重寫任務背后的非技術動力并加以管理，例如增加特性交付的速 度，或減少硬件方面的成本。Krikorian表示，整個重寫的流程以及相應的流程報告并須由數據驅動，其中可以包含成本節約、特性交付速度、可靠性、性 能以及穩定性方面的指標。必須避免將此當作一件趣事的想法，而是必須展示這些實驗的成果。

Krikorian在演講的最后結尾時表示，承擔了系統重寫任務的技術領導或架構師經常會處于一個危險的位置上。在重寫中使用了大量的工程資 源，而同時又不能在業務上交付任何新特性。在保持系統運行時進行重寫的工作必須盡量保持在很小的范圍內，并且必須使用例如持續集成和持續交付這樣的技術定 期地進行整合。同時對重寫的系統中的代碼質量并須加以密切關注。

按照康威定律，理想的架構與團隊的結構也必須一致，正如Krikorian所說：

架構影響了團隊的結構，后者又反過來影響了前者……

在slideshare上可以找到Raffi Krikorian的這場“ 在運行過程中進行架構重寫 ”演講的幻燈片。 O’Reilly軟件架構大會 于2015年三月在波士頓舉辦，在會議的網站上可以找到更多的細節，其中包含了這些演講錄像的鏈接。

查看英文原文： Raffi Krikorian Provides Guidance for “Re-architecting on the Fly”