談談技術債務

文章首發於公衆號 松花皮蛋的黑板報
做者就任於京東,在穩定性保障、敏捷開發、高級JAVA、微服務架構有深刻的理解

最近在我身上發生了這麼一件事。我主要負責內容創做的，提供了一個寫入的邏輯接口，可是在校驗鏈中對圖片來源空間包括域名進行了校驗，你能夠理解空間是一種業務名位置，空間涉及到精細化成本管理。接口使用者在測試時發現寫入失敗，由於圖片不合法。那碰到這種狀況，若是是你，你是另外提供一個圖片轉鏈服務呢？仍是寫入時判斷是不是他在調用而後對其圖片特殊對待呢？仍是強調規範而後讓使用者自行解決呢？

接口使用方以爲不該該由他們來承擔這種改造，不該該過分關注服務提供方的內部細節，畢竟上傳的圖片都是京東的圖片。可是呢，若是由我來處理，校驗鏈改動又是件很棘手的事，或者對其來源單獨放開圖片校驗，這又是一個極其個性化的需求。我以前說過，接口不該該爲個別服務。並且，調用方不遵照我約束的規範，響應異常很正常。婆說婆有理，公說公有理。最後組織干係人討論一番，結論是短時間上先對其來源內容不進行任何機審，長期上對校驗鏈進行改造。

你看，在協做中很容易由於項目緊迫對質量妥協，從而引入技術債務。不是還有長期方案嗎？別得意太早，需求是永無止境的，你可能根原本不及對其改造，或者把這事給忘記了。日積月累，最後難以維護。

那對技術債務如何進行管理呢？

咱們先來對技術債務下個定義。我經過引入一個爛設計解決了一個在很短期內不可能完成的事。就比如借款買房。不過咱們知道一個軟件系統內部質量差的話，不論是一不當心形成的仍是因爲能力問題形成的，它都會使得咱們在軟件修改或添加新功能時，須要的工時遠遠超過預估值。也就是說技術債務和經濟債務同樣，都是須要償還的，剛提到的額外付出的工時就是償還的利息。

在下定義時其實已經指明瞭該怎麼處理，就是咱們能夠專門花一些額外的工時重構相應的爛代碼。就比如對待財務債同樣，少許屢次地償還。藉助償還財務利息及本金的思惟，咱們能夠很方便地識別出須要幹掉哪些爛設計。若是有一個很爛的系統，咱們不須要爲其添磚加瓦，這個爛設計就不是問題，也就是說，只有須要修改老舊系統的代碼時，纔有技術債利息的事。爛設計但穩定沒問題的代碼不須要調整，與其相反，那些高頻修改的代碼區域須要格外敏感地重構，由於這些的利息率是至關陡峭的。代碼越是修改，引入爛設計的風險越大。

總之，由於技術債務的存在，若是後續須要添加緊急需求的話，仍是老老實實把技術債務管理起來吧！經過重構和代碼評審增強代碼質量，讓待解決的缺陷愈來愈少！讓產品經理和項目經理排期專門處理技術債務！

文章來源：www.liangsonghua.me

做者介紹：京東資深工程師-梁鬆華，在穩定性保障、敏捷開發、JAVA高級、微服務架構方面有深刻的理解