Pycon 2015 - Technical Debt - The Monster in Your Closet
(www.slideshare.net)
IngramChen
積分 5
我們公司的系統都有寫 unit test，所以在追加功能和維護上都相對簡單 (就成本低一點，大家也比較敢改東西)。我自己寫了快十年的 unit test，這件事簡單說就是倒吃甘庶：一開始很累，因為要建一些基礎設施。到了中期稍微好了一點，但你還是會覺得有負擔。到了後期這負擔還是在的，但這個階段沒 test 還真的不曉得怎麼寫怎麼改了。(沒 test 通常就是照前輩流傳的 沒壞的東西不要去動 的準則去做了，想當然爾什麼功能都加不太上去)
沒 test 的 legacy code 這種債務我們很低，不過系統久了，其他地方還是會有債務的。我們去年花了一點時間還了一筆技術債，就是升級 Cassandra，從 thrift 到 CQL。大概花了一、二週寫了一些橋接的程式讓兩種 drivers 能共存。這筆債還了之後我們後來加功能就變得輕鬆很多，直覺好寫又不容易出錯，效能又變好。(大部份的人都對 Cassandra 不熟，我打個比方好了，改版的進步大約是一開始是純 js 的亂七八糟碼，然後後來導入 jQuery 那樣，巨大的改進)
這篇投影片的內容建議：你應當先清償債務利息最高的部份。說得真是好啊，把最大的路障移走後面自然快速通暢了。我上面的例子對我們單位來說就是清掉擋路的大石塊，爽得咧！當然這是一次成功的清償我才會拿出來臭屁啊，其實也有多次的清償都失敗的 (例如 refactor 後也沒什麼顯注改善之類...)