程序員，技術債你還清了嗎？

「我很想改進這種設計，但是我沒有時間。」

「我真的很想整理這些，但是這不屬於這個任務的範圍。」

「我們現在沒有時間重新思考這個模塊的架構。」

這些話把每個開發人員的耳朵，都磨出繭自來了。更不像話的是，每個開發人員也整日把這些話掛在嘴邊。

更讓人心有不甘的得失，很多時候這些都是應該做的事情。

曾經我也很希望提供優雅美觀的代碼，但是現實情況是，我的老闆付錢給我，讓我提供對他們和他們的客戶有用的功能，即價值。

專心為客戶提供價值，是現代科技業務最大的重點，而且隨著Eric Reis的「精益創業」的流行，以及其對整個「科技產品開發」思想的啟發，這個重點變得更為突出。

但是，我們所有人（包括Reis和他的朋友）也都認識到，全心全意提供面向客戶的功能是一個錯誤；這是導致我們陷入熟悉的「技術債務」的罪魁禍首，接下來就是「技術破產」，最終我們在恐懼中承認失敗，所有工作都白費，所有代碼必須「完全重寫」。

因此，作為軟體開發人員我們普遍認為：維護（即保持代碼庫處於健康狀態），是我們工作重要的組成部分。

但是，如果我們都認識到保持健康的代碼庫，是工作的重要部分，那麼為何我們常常發現「價值」，佔據了我們100%的工作時間，而投入到「維護」的時間幾乎為0呢？

我們知道維護是必須的。我們的技術負責人知道。我們的首席技術官常常說起，有時甚至連CEO都熟悉「技術負債」的概念、以及技術人員對此的恐懼。

然而，在現實中，我們工作的重點依然沒有變。「我現在沒有時間該這個問題。」

維護的正當理由

這個問題有什麼正當理由嗎？

最常見的解釋理由是「產品經理是大壞蛋」的理論：我沒法去做技術維護，因為這個邪惡的商人不斷給我分配功能開發。

我發現這個解釋不夠充分，原因有兩個：

首先，產品經理與我們形容的形象相反，他們也是講道理的人。他們也知道而且很擔心技術債務，他們也想避免這種情況。

而且即便他們不想這麼做，我們還有技術人員，保持技術方面的健康是技術領導團隊的工作。

其次，根據我們以上的觀察，維護是你的工作的一部分。

從什麼時候開始你的工作需要領導批准？醫生不會因為說「我們承諾在本季末保持客戶的健康」，才去做徹底的檢查和測試。

一個專業的承包商不會在確認地面足夠支撐建築的結構前，就開始鋪設地基。

那麼這與軟體有何不同？很多原因在於我們這個行業的極端不成熟。

我們沒有足夠專業的標準，讓保持代碼健康成為流程中不可或缺的一部分，就像建築中的安全檢查，或醫療服務中的衛生處理。

這反過來又說明，我們沒有足夠的專業能力，來證明這樣的標準，也就是說我們在上一個項目中花了時間來「償還技術債務」，但卻沒有成功。那麼我們怎麼可能要求，在下一個項目中還這麼做呢？

當然，對於那些追隨Bob Martin叔叔以及其他許多年來一直說同樣的話的人來說，這個結果並不新奇。

但是我相信事情還沒完，不全是因為我們不夠優秀（不夠專業）做正確的維護。部分是因為我們不願嘗試。請記住——我這裡說的是「我沒這麼做」，而不是說「我努力了，但是做不到」。

為什麼我們不願嘗試維護？

假設你是一個典型的開發人員。某一天，他們可以選擇創造價值還是做維護。我知道他們（幾乎所有人）都會選擇前者。

儘管他們的技術負責人、首席技術官和同事每天都在討論技術債務的憂患。這是為什麼呢？你（或同事）因為交付對客戶非常有利的功能，而受到稱讚的情況有多少次？

現在，比較一下你（或同事）因為做了代碼重構、維護或寫技術文檔，而受到表揚的情況有多少次？

或者，從另一個角度來看，對於你個人而言，如果你們計划了100個給客戶的功能，但是有1個未能交付，那麼你認為後果是什麼？

比較一下，對於你個人而言，如果有100次機會，可以改進或維護代碼庫，但是這100次你統統沒有做，那麼你認為後果是什麼？

如果你的工作環境，與我見過的所有工作環境都很相似的話，那麼你知道交付優秀的維護工作，可能你的同事會感激你，但是交付功能可以讓你贏得升職。

你會選哪個？這個結果一點都不驚訝或新穎；憑我對市場經濟僅有的一點了解，我也知道每個人都會努力爭取最大化利益。

如果你按照代碼行數付錢，那麼相同的功能，你拿到的代碼量將是10倍之多。如果每改好一個bug，就可以收到一份獎金，那麼你的應用程序裡面會布滿bug，以方便他們日後慢慢改。

如果維護代碼沒有切實的獎勵，那麼你就會陷入技術負債。

我們怎樣才能將開發人員100%投入到價值的精力轉移到0%的維護工作上呢？簡單來說，經理不能只是動動嘴皮子；不要再喋喋不休地討論，如何解決技術債務。相反，應該表明你願意付錢找人解決這個問題。

平衡在維護中的重要性

平衡在這裡很重要。雖然我們不希望開發人員在價值和維護上投入到精力比例為100比0，但也不想變成50比50。

如何將維護相關的工作，作為年度考核中的一部分呢？或者作為開發規範的一部分呢？

在問開發人員「這些功能做得怎麼樣了？」的時候，每問10次，可否有1次問「最近代碼改進怎麼樣了？」

一旦人們明白，保持代碼健康也會受到獎勵，包括他們的升職、加薪和公司內的位置等會受其影響，他們就會自己找時間、範圍和精力來完成。

不過，為了有效判定某人是否達成了某個目標，你需要能夠度量。度量代碼的質量，或代碼質量改善度，並不是一個可以輕易解決的問題。如何度量這個話題需要開一篇博文、寫一本書或學術研究來解釋。

本文的描述符合你的經歷嗎？還有什麼合理的原因，導致我們不願償還技術債務嗎？或者也許這壓根不算什麼問題？請在下面留言。

作者：Jhonny，資深軟體開發人員，熟悉C#、javascriptnode和JS、ruby，以及一些工具AnuglarJS、nHibernate、rails、mongodb等。

譯者：彎月，責編：胡巍巍

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