「遺留代碼是傳奇！」

【CSDN 編者按】只要在軟體行業待得足夠長，就不可避免會面臨一個棘手的問題：修復遺留的代碼庫。遺留代碼是很多程序員眼中的「大麻煩」，那究竟為什麼如此「討嫌」呢？本文以一則寓言為引，寫出了遺留代碼的產生原因和解決辦法——「我們不是遺留代碼……我們是傳奇。」

作者 | Michael Stahnke

譯者 | 彎月，責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

在一個不起眼的小角落裡，有一段默默無聞的小代碼。

它厭倦了別人叫它遺留代碼，它厭倦了被人們遺忘在角落。畢竟，它還在負責一段業務邏輯。然而，儘管它處理了所有的交易，提供了許多價值，還幫助了許多用戶，但還是免不了被人取笑。

小代碼很難過。「我是這項業務的支柱！」它大喊道，然而沒有人聽到它的吶喊聲。人們不願理睬它，甚至不想與它互動。小代碼經常聽到有人用很刺耳的綽號稱呼它。就在上周，有人接到了修改小代碼的命令，但是那個人的話深深地刺痛了小代碼。

「我不想碰小代碼。它太丑了，不符合我們目前的做法。每次我碰小代碼，就會走霉運。」一位團隊負責人說。

小代碼傷心地坐在角落裡哭泣，然而它沒有眼淚。後來，小代碼決心振作，它覺得自己需要品牌推廣。於是，它開始與其他代碼交談。雖然，小代碼和其他代碼並不是好朋友，但它們似乎總是在調用它。

「你好，微服務先生，為什麼大家那麼喜歡你呀？」

「哦，你好，」微服務回答，一邊快速地瞟了一眼小代碼，顯然它想儘快結束這場對話，「可能是因為我們的目標很容易定義，我有測試覆蓋率，而且我很容易部署。」

「哦，」小代碼說，「都有哪些人負責你的工作呀？」

「整個團隊。他們負責編寫、重構，並將我部署到Kubernetes上，然後更新並自動擴展規模。」

「哇，聽起來很有趣。什麼是kubernetes？」小代碼說，「你合適生產嗎？」

「生產？」微服務回答道，「那是什麼？」

「哦，不。」小代碼回答道。

它意識到它正在與「最好的」代碼交談——這些代碼在技術上是完美的，但對用戶沒有幫助性。我們的小代碼獲得了很多諸如此類的反饋。很多新系統都有新想法，但是小代碼的職責是運行業務，過去是，現在是，而且將來也是。

在遭到一系列的碰壁後，小代碼想了各種辦法，並試圖與另一個代碼庫交互。

「你好。你知道為什麼人們不喜歡我嗎？」

這個代碼庫體型龐大，而且好多天都沒有刮鬍子了。它看起來有點狼狽，但總得來說，它看上去很有智慧。

狼狽的代碼淡淡地說：「當然沒人喜歡你了，因為你是遺留代碼。」

「沒有必要當面給我難堪吧。」小代碼說。

「不，不。遺留代碼的意思是說，你負責運行業務。你有巨大的影響力。你承擔著各種職責……但也意味著，與你愉快地合作的時光也已經隨著那些偉大的人一起遠去了。人們採用了新的模式、實踐和工具。現在我的處境也是同樣。」

「是嗎？」小代碼有點傷心地問。

「當然，遺留代碼從不是貶義詞。遺留代碼意味著這些代碼長期有效，它們辛勤地工作了很長時間，而且在經歷了大風大浪以後依然倖存了下來。像你和我這樣的代碼的職責是運行業務，我們不斷堅持完成任務。領導都想要成為歷史傳奇，代碼庫也一樣。」

「但是，那些微服務總是在談論每個人都喜歡它們。它們說我是一枚數字棄子。」

「它們這麼說只是因為嫉妒你。這些服務中有多少能見光的？沒有你或我，有多少人能夠真正完成自己的工作？當然，這本來是他們的本職工作，但通常人們都無法正確地抽象代碼。這些服務最終都會成為調用我們的介面。雖然我們是遺留代碼，但是沒關係，因為我們提供了價值。其他代碼庫希望發生交易、延遲，但我們擁有健康。」

「那麼，為什麼沒有專門的團隊管理我們？」

「人們喜歡重新組織他們的工程團隊。他們會分領域、微服務或子系統。很多時候，在人們的組織結構分裂之前，我們就已經存在了。我們永遠在默默無聞的小角落，被人遺忘。但也有一些細心的人會看到我們，無論他們在哪個隊伍。」這個很聰明的代碼說。

「嗯。因為我們工作得很好，所以人們忙於處理其他事情，才把我們忘了，是嗎？」

「也不能這麼說。人們知道我們的存在。他們知道我們做出的貢獻。他們只是想以更新的方式工作。有時他們會投資新技術和工具。我常常在想，究竟哪些產品會投入生產。記住，生產才是我們展示自我價值的地方。」

「我一直都在生產中……」小代碼欣喜地說，「謝謝你。」

「不客氣。」

小代碼突然停下來轉身微笑著說：

「我們不是遺留代碼……我們是傳奇。」「這就是我們的精神。我們提供價值，也不枉我們來這世上走一遭。我們為此感到自豪。」

以上是一個童話小故事，但這個故事說明的問題非常真實。請注意，下面來讓我們看看為何軟體失去了管理員，以及如何才能防止產生沒人喜歡、悲傷而又孤獨的小代碼。

由於缺乏軟體所有權而引發的問題

每當一部分代碼庫沒有明確的所有者時，問題就會顯現。即便現在還沒有造成問題，但遲早也會崩潰。

下面這些跡象表明代碼出現了所有權問題：

• 系統中是否存在無人管理的組件？

• 代碼庫中是否存在你甚至無需向新員工介紹的地方？

• 代碼或系統中的某些部分是否來自舊時的專家和英雄掌握的部落知識？

如果你中了上述的某一條，則很有可能你遇到了遺留代碼的問題……呃……傳奇代碼。

如果在提交代碼後，這些代碼就交由別人負責，那麼這不叫所有權，這更像是到期的租約。一旦功能、子系統或應用程序發布後，由誰來負責維護？把這些工作推給運營團隊或其他不太走運的團隊？這可不是維護代碼庫的最佳方式，因為他們幾乎沒有領域知識，無法維護基礎設施的穩定，或承擔起升級和改進的工作。

何時需要代碼所有權？

生產中的所有代碼都必須由某人維護嗎？

通常在我們的行業中，SRE（Site Reliability Engineering ，網站可靠性管理）團隊的任務是負責所有損壞的東西。當軟體沒有一個明確的所有者時，就不得不進入SRE的收容所，久而久之SRE團隊就積攢了一堆數字雜物，他們還需要確保系統的政策運行。但這對SRE來說很不公平，有點浪費他們的才華。但是，事情是如何演變到這一步的呢？

通常，衡量開發團隊績效的指標是新功能的交付或開發速度。然而，他們實際的績效衡量並非出自這些角度，而且他們也會因為可操作性、可追溯性、保持庫更新而得到獎勵……基本上，這些都不是功能。由於開發團隊不理會維護的責任，那麼通常最終這種責任都會落到運營團隊身上。運營團隊的績效指標是穩定性和可靠性。他們可能會用牛頓第三定律系統管理法來維護系統，即「只要你不碰系統，它就會保持正常運轉。」我們知道這種狀態只能維持一段時間，但在此之前，世界各地的運營團隊都會如此操作。

為什麼所有權會不清不楚？

一個軟體喪失所有權，或所有權模糊的主要原因有四個：

• 編寫代碼的人不在了；

• 曾經有所有者，但因為團隊重新組建，所有權轉移或消失了；

• 舊軟體已被棄用，但新軟體尚未能完全取代；

• 從一開始就沒有明確的所有權模式。

有一句話雖然聽起來淺顯，但我還是想重點強調一番：你不能在寫完代碼後就轉身離開——但人們總是這麼干。

在功能測試完畢後，團隊不可避免地會發生變化，他們需要投身新的項目。而構建好的軟體已投入生產，很多人正在使用和依賴這些功能。這些人希望軟體持續發揮作用，並常常希望有人改善該軟體。但是，很多時候，一旦產品或功能投入使用後，就會被人拋諸腦後。

這可能是最小化可行產品開發的必然結果：快速交付產品，並快速獲得反饋。但問題是我們發現這種模型往往不完整，在收集到有價值的數據並完成反饋循環後，該模型的計劃就結束了。但是人們常常忽略的一點在於，那些用來獲取反饋的軟體現在怎麼樣了？我們應該從一開始就建立完整的步驟，來防止這種情況的發生。

規劃軟體的持續維護性是構建軟體的責任的一部分。編寫和交付代碼很有成就感，但是寫完代碼後你的工作並未就此結束，真正的工作是持續維護和更新這些代碼。

與永久性的運營成本相比，軟體最初的開發成本幾乎可以無視。

如何鼓勵人們承擔軟體的所有權？

或者，如果有些代碼失去了所有者，你該怎麼辦？

許多組織使用疊加矩陣模型（Overlayed Matrix Model），例如Spotify的公會或Valve"s cabals，來為孤立代碼項目分配所有權。我們也嘗試過，但說實話，我並不覺得這種方式有效。就其本質而言，公會工作不是你的主要工作。因此，你在公會中的表現並不能反映到績效考核中。因此，這種方法並不能真正解決所有權的問題。而且這種方法還會削弱職責。

下列是一些我認為可行的方式：

• 有些公司讓團隊承擔起維護的責任。假設你所在的團隊負責計劃和付款，這時有一個孤立的項目已經上線，儘管與計劃和付款無關，但也會成為你們團隊的責任。這種方式比公會更有效，因為團隊承擔的工作就會計入績效考核中。但有人不喜歡這種方法，因為這種方法有點混亂，任務的職責與團隊的核心領域無關。人們喜歡完美的領域，但我們並沒有生活在一個完美的世界裡。任何在生產環境中運行的代碼都需要有人直接負責其維護工作，即便所有者不理想，但也總比沒有得好。

• 另一種策略是在早期在代碼庫中建立通用實踐。如果某個開發人員同時兼顧多個相似的代碼庫，那麼在這些代碼庫中工作時的思維跳躍成本必然會降低。在這種環境中，測試、構建、部署、更新的運行方式都相同，任何一個維護某個代碼庫的人都可以介入並維護另一個代碼庫。雖然使用的語言或域模型可能不盡相同，但你可以使用相同的工具。開發人員可以通過抽象專註於運行測試，你可以按照相同的方式構建，相同的方式進行測試，並以相同的方式部署。

說到底，改善代碼所有權的問題關係到設計軟體和構建軟體的方式。具體來說，軟體在設計時需要考慮到分配任務、衡量考核以及監控，比編寫正確的軟體更高層的目標是，能夠驗證軟體是否能夠正常工作。如果想在設計時考慮診斷問題，就必須提前了解開發人員的意向。通常，他們都沒有這種意向，除非接到運營的任務，因此，你可以在績效考核項中加入適當的考察目標和調試目標。

軟體所有權與工程的職能無關。這是關於人的問題，這些人花時間操作、測量和維護。請記住，與多年或長期的運營、更新以及維護成本相比，軟體開發新功能的成本幾乎等於零。

軟體缺乏所有權不是一個簡單的問題，下面是我的一些建議：

• 即便你不願承擔某項工作，也不意味著這項工作會憑空消失。你需要做好計劃，通過團隊重組、制定維護計劃，在未來的道路上做好這項工作。

• 向新員工介紹運營業務的代碼庫。一個常見的問題是，如果讓新來的人接手新工作，那麼能夠承擔遺留系統工作的開發人員或工程師的比例就會縮小。這會孕育英雄文化，不適合擴展規模。

• 接手代碼庫的人不了解實際情況。可能兩年後，這個人就會接手你的工作。你需要記錄各項決策背後的原因，以及決策的內容，提交代碼的時候填寫良好的注釋。

• 對於開發人員來說，「成也代碼，敗也代碼」，你需要在急於拋棄舊代碼或替換系統的功能時權衡利弊。但是，請永遠不要忘記，我們親愛的小代碼，以及多年來它提供的所有功能、交易、用戶、資金和吞吐量。小代碼需要一點愛，它還有很長的路要走。

原文：https://circleci.com/blog/the-little-legacy-code-that-could-a-fable-of-software-ownership/

本文為 CSDN 翻譯，轉載請註明來源出處。

【END】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！