文章首發於公眾號 松花皮蛋的黑板報 作者就職於京東,在穩定性保障、敏捷開發、高級JAVA、微服務架構有深入的理解 最近在我身上發生了這麼一件事。我主要負責內容創作的，提供了一個寫入的邏輯介面，但是在校驗鏈中對圖片來源空間包括功能變數名稱進行了校驗，你可以理解空間是一種業務名位置，空間涉及到精細化成本管理。接 ...
文章首發於公眾號 松花皮蛋的黑板報
最近在我身上發生了這麼一件事。我主要負責內容創作的，提供了一個寫入的邏輯介面，但是在校驗鏈中對圖片來源空間包括功能變數名稱進行了校驗，你可以理解空間是一種業務名位置，空間涉及到精細化成本管理。介面使用者在測試時發現寫入失敗，因為圖片不合法。那碰到這種情況，如果是你，你是另外提供一個圖片轉鏈服務呢？還是寫入時判斷是否是他在調用然後對其圖片特殊對待呢？還是強調規範然後讓使用者自行解決呢？
介面使用方覺得不應該由他們來承擔這種改造，不應該過度關註服務提供方的內部細節，畢竟上傳的圖片都是京東的圖片。但是呢，如果由我來處理，校驗鏈改動又是件很棘手的事，或者對其來源單獨放開圖片校驗，這又是一個極其個性化的需求。我之前說過，介面不應該為個別服務。而且，調用方不遵守我約束的規範，響應異常很正常。婆說婆有理，公說公有理。最後組織干係人討論一番，結論是短期上先對其來源內容不進行任何機審，長期上對校驗鏈進行改造。
你看，在協作中很容易因為項目緊迫對質量妥協，從而引入技術債務。不是還有長期方案嗎？別得意太早，需求是永無止境的，你可能根本來不及對其改造，或者把這事給忘記了。日積月累，最後難以維護。
那對技術債務如何進行管理呢？
我們先來對技術債務下個定義。我通過引入一個爛設計解決了一個在很短時間內不可能完成的事。就好比借款買房。不過我們知道一個軟體系統內部質量差的話，不管是一不小心造成的還是由於能力問題造成的，它都會使得我們在軟體修改或添加新功能時，需要的工時遠遠超過預估值。也就是說技術債務和經濟債務一樣，都是需要償還的，剛提到的額外付出的工時就是償還的利息。
在下定義時其實已經指明瞭該怎麼處理，就是我們可以專門花一些額外的工時重構相應的爛代碼。就好比對待財務債一樣，少量多次地償還。藉助償還財務利息及本金的思維，我們可以很方便地識別出需要幹掉哪些爛設計。如果有一個很爛的系統，我們不需要為其添磚加瓦，這個爛設計就不是問題，也就是說，只有需要修改老舊系統的代碼時，才有技術債利息的事。爛設計但穩定沒問題的代碼不需要調整，與其相反，那些高頻修改的代碼區域需要格外敏感地重構，因為這些的利息率是相當陡峭的。代碼越是修改，引入爛設計的風險越大。
總之，因為技術債務的存在，如果後續需要添加緊急需求的話，還是老老實實把技術債務管理起來吧！通過重構和代碼評審加強代碼質量，讓待解決的缺陷越來越少！讓產品經理和項目經理排期專門處理技術債務！
文章來源：www.liangsonghua.me
作者介紹：京東資深工程師-梁松華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深入的理解
