文章出處
文章列表
關于丑陋代碼
工作中經常看到很多丑陋的代碼，或者，自己寫的代碼過一段時間之后自己也覺得很丑陋，促使你不斷的去重構。
那么，這些丑陋的代碼是什么時候編寫的呢？它們到底存在多久了呢？
大多數情況下，這些丑陋代碼已經存在有些年頭了。即使是你一手支撐的產品或項目，經過幾個版本的迭代之后，1-2年也過去了。
在這些看起來丑陋的代碼中，很多沒有進行單元測試，可測試性不高，或者根本不可測。或者它們也有可能是 TDD 實踐后的產物，有著不錯的單元測試覆蓋，但依舊是丑陋的代碼。
但經過漫長的生命周期后，它們存活了下來，并且至今仍發揮著效力。因為，這些丑陋代碼所實現的業務邏輯是有效和有用的，而業務邏輯所描述的產品還仍然很有生命力。
所以，丑陋代碼有其存活的理由。只是，這些丑陋的代碼增加了維護的難度，你需要不斷的償還這些技術債務，甚至一直拖欠著。
何時單元測試
在新的項目中，我通常不會直接編寫單元測試代碼，直到：
- 當我知道如何構建我正在嘗試構建的系統時
- 當我知道我們的客戶是真正的需要我們所要構建的系統時
- 當我知道我所寫的代碼將存活一個月以上時
直到此時，我才能明確的表達所構建系統的原型，并且通常其已經不再是一個將被拋棄的原型。
難道這就意味著我有權說我可以不寫單元測試嗎？是的。
因為在此之前，我們一直在不斷的等待各方反饋，以確認我們正在做著正確的事情。而一旦我們已確認所做的事情是正確的，那么就可以啟動自動化測試了。
單元測試的作用
- 幫助理解需求
- 對設計的快速反饋
- 提高實現質量
- 測試成本低
- 利于重構
- 文檔作用
文章列表
全站熱搜
留言列表
