【技術債】一時方便的技術債(Technical Debt) 遲早要還的

剛開始從事程式設計的新手,他可能不明白複製並貼上對程式碼可能造成的潛在傷害

他只是憑著直覺,順手就做出了複製並貼上的舉動。

在這種情況下,他並不是在明明知道這麼做會在日後付出代價、經過理性的評估及算計之後,仍然決定這麼做。

但是,「技術債 (Technical Debt)」在日後所會造成的傷害並不會因此而減少,甚至可能因為對債務的一無所知,不知應該加以清償、因而讓債務日積月累、利息愈滾愈多。

 

在專案方面

不少團隊都會因為專案時程的關係,

有些開發團隊或個人會想要打破「關注點分離的開發模式(例如: MVC)」,

用看起來速度很快的方法來做,基於專案時程的要求基本上沒錯,

但是這種打破這種模式的作法很容易用數以倍計的速度累積大量的技術債」 (Technical Debt)

這些技術債會讓後續接手的人 (也有可能和開發人員是同一人) 在維護上付出數以百倍計的心力來閱讀與掌握程式碼的邏輯

若這些程式碼是產品的一部份,問題會更加嚴重,

但會這樣做的開發人員或團隊,往往很容易以忽略它的角度來看這些問題,

因此現階段這樣的情況並沒有太多改善,

我們還是會很常在部份 ASP.NET 程式裡看到一大堆的義大利麵程式碼,

也能在一堆呼叫資料庫的程式內看到 SQL Injection。

 

複製貼上是要還的

copy-and-paste

當你察覺了原程式碼中有一段程式碼,可以在接下來的實作中被重複運用

當時你並沒有採取類似重構的方法,把這段程式碼給萃取(extract)出來,

而是繞過應該要有的萃取動作,直接使用了複製並貼上(copy and paste)的招數

把現有可以重複使用的程式碼,直接抄過來(或經小幅度修改)使用,

一時之間,這樣做當然很快,但是,對程式碼長遠的發展而言,會造成負面的影響。

 

註解與說明文件的重要性

多拉a夢思考

技術債還有可能發生在程式碼的註解、或是設計及程式碼的說明文件,

有些團隊,會為了節省撰寫註解或文件的時間,而減少了為程式碼撰寫註解或撰寫說明文件的數量,

這當然可以在短時間內得到好處,因為開發團隊節省了人力和時間,

但是就長遠來看,註解和文件有助於程式碼及設計的可讀性,有利於團隊成員間的知識、資訊交流,以及日後系統的維護及修改,

倘若註解及文件有不足的情況,開發團隊自然也會漸漸為此付出代價,

忽略測試案例的撰寫、或是僅撰寫不夠充份的測試案例,也是常見的技術債。

而在程式中,用TODO式的註解,標註那些你覺得應該要寫,卻還沒寫的程式碼,當然也是一種技術債。

 

每一則警告訊息都是一個一個的彩蛋

要爆了

甚至像忽略編譯器所展示的警告訊息,即使程式碼仍可通過編譯,但每一則警告訊息,都像是一個潛在的未爆彈,可能在任何時刻爆炸,進而對你產生傷害。

又好比,明明知道某種程式的寫法可能會造成緩衝區溢位,或是遭受SQL資料隱碼攻擊,但是,為了貪圖一時之快或便利,還是寫下了那樣的程式碼,這同樣也是一種技術債。

 

 

參考1: http://www.dotblogs.com.tw/regionbbs/archive/2013/09/13/118410.aspx

參考2: http://www.ithome.com.tw/node/71807

訂閱
通知
guest
0 留言
預約回饋
查看所有留言