在敏捷測試日2015大會上，Thomas Bradford講述了他維護一個單體Java系統的經歷，該系統測試覆蓋率為零，而且有大量的技術債務。InfoQ對他進行了采訪，內容涉及他們在系統維護過程中面臨的問題，他們積累的技術債務，他們為什么決定采用一種不同的方法以及他們如何提高團隊士氣。

InfoQ：您能詳細描述下你們在維護這個大型Java系統中面臨的問題嗎？最大的問題是什么？

Bradford：我是后來加入這家公司的。我在2015年年初受聘為工程部門的副總裁，任務是幫助開發人員解決困擾他們將近10年的質量問題。具體地說，就是他們根本無法做到修改系統或者修復Bug而又不引入更多的問題。

InfoQ：您能描述下你們面臨的技術債務嗎？

Bradford：當前的系統是在一個非常短的時間構建而成的，而且是單體系統。因此，測試覆蓋率幾乎為零。此外，代碼一團糟，滿是重復的、長得令人難以置信的方法。它就是維護人員的噩夢。

更嚴重的是，幾乎沒有做過任何工作讓事情變得可控。Bug交給了賣力的新手處理，而不是導致那些Bug的團隊，而團隊被推動著“快速前進”，給新手們留下了夠他們處理一生的Bug。

InfoQ：是什么讓您決定開始采用一種不同的方法？

Bradford：在我同現在的技術負責人交談的過程中，他們告訴我，他們實際上已經兩次重寫了他們的產品，每次的結果都類似。所以，我建議采用一種不同的方法，不只是戰略上的，而且是哲學上的。

從戰略上講，我知道，維護這個單體Java系統，我們永遠不可能還清債務，而且會深陷其中，沒完沒了，最終我們會發現自己陷入了一個無力發布任何東西的境地，不是因為我們導致系統崩潰，就是因為所有的開發人員在厭惡中離職。

從哲學上講，我希望開發人員能夠從過去多年的積累中脫離出來，嘗試采用一種完全不同的方法解決問題，像新手一樣。

InfoQ：您采取了什么措施來提高系統的測試覆蓋率？

Bradford：簡單來說，我們沒有采取任何措施。

該系統最初是通過測試自動化來保持可控狀態。在我來之前，公司已經采用外包的方式創建了一個Selenium測試套件，用來代替在那之前一直使用的人工測試矩陣。我們還嘗試建立了單元測試覆蓋率，但主要是使系統最難弄的部分可控。然而，這兩個方法都不是最終的解決方案。

真正的解決方案是徹底地重構架構——將單體應用解耦成獨立的服務——并采用一個完全不同的技術棧來實現。

InfoQ：您是如何處理團隊士氣的？

Bradford：我來的時候，團隊士氣已經非常低落。我不知道還會不會更差。開發人員已經完全敗給這個系統了，害怕修改他們的軟件，作為一名軟件工程師，這是你能經歷到的最差的感覺之一了。

不過，情況正在好轉。在賦予了信任和自主性后，開發人員正在克服過去的恐懼，挖掘他們的創造性，同時開發出質量比過去高出許多的軟件。

InfoQ：對于有大量的技術債務需要處理，而大多數開發人員對于他們的境況又非常不滿的情況，您有什么建議嗎？

Bradford：技術債務這種東西是可控的，而且必須及早控制。“我們將稍后清理”的主意可能會讓產品人員高興，但現實情況是“稍后意味著永不”。如果你發現自己處于同我們類似的境地，我們的單體系統的內部架構根本無法支撐我們有效地償還技術債務，那么無論如何都要讓公司償還債務，他們必須決定是否要為了避免組織長遠的失敗而削減短期的功能輸出。大部分公司都希望在商業競爭中生存下來。

作為專業的軟件工程師，我們有責任保證我們的工作質量。外部參與者可能會對我們施壓，讓我們“再快點”或者在質量上妥協，但是，我們不是唯一必須承受那些決定的影響的人。最終，這些決定會回過頭來咬組織一口。為質量辯護，高舉警告標識，堅持用“正確的”方式做事，這是我們的工作，即使這個了不起的組織沒有看到這樣做的長期價值。

查看英文原文：Technical Debt and Team Morale when Maintaining a Large System