「技術債務（technical debt）」這個詞是由ward cunningham 發明的，用來描述為了在最後期限前實現某個專案任務而讓開發團隊做某種技術上的妥協。
這裡有兩篇部落格文章，uncle bob 和 martin fowler 分別在裡面描述了幾乎所有專案都可能會遇到的各種技術債務。
編碼混亂並不是一種債務。編碼混亂就是編碼混亂。技術債務的產生是由現實的工程約束造成的。這是有風險的，但卻是值得去做的。而程式設計師讓編碼混亂的行為永遠是不理智的，它永遠都是因為懶惰和不專業造成的，而且將來你也永遠還不清這種債務。混亂永遠都是一種錯誤 …在 technical debt quadrant 這篇部落格裡， martin fowler 認為編碼混亂就是一種技術債務，是程式設計師在不經意間犯下的錯誤。martin fowler 接著描述了四種型別的技術債務：故意的/大意的，故意的/謹慎的，非故意的/大意的，以及非故意的/謹慎的：你承擔的技術債務越多，你就應該越發自律。你應該做更多的測試，更多的結對程式設計，更多的重構。技術債務並不是你製造**混亂的通行證。技術債務實際上是要求你更清晰的** … 當你決定去欠下技術債務的時候，你最好能確保你的**保持清晰易懂。保持系統的清晰易懂是你將來償還債務的唯一途徑 …
做這些區分的目的不在於判斷它是否是債務，而是判斷是思慮過的還是粗心的 …注意到，有一種特殊的債務既是既是大意的又是思考過的：不僅僅謹慎產生的債務和大意產生的債務有區別，考慮過的債務和非有意的債務更要有區別。謹慎思考過的債務的例子就是」故意的債務「，因為團隊已經知道他們將會欠下債務，他們會考慮是提前發布乙個不成熟的版本會得的利益多還是放棄這次發布產生的代價大。乙個團隊如果沒有反覆思考他們的設計，那他們就會欠下粗心大意產生的債務，他們甚至沒有意識到自己已經陷入了無法自拔的債務泥潭裡。
經常會有這種情況出現，乙個專案你幹了一年後才明白你實際應該採用何種的設計架構。也許我們應該這樣計畫專案：花一年的時間去開發它，然後扔掉重建，但沒人會認同這種做法。除了此時你會明白什麼的設計才是你應該採取的設計外，你還要明白，這就是乙個非有意產生的債務。你是否也認為混亂的編碼、快速但質量低下的程式實現是某種形式上的技術債務呢？或者，你認為這些只是由於技術水平低下造成的，完全可以避免，即使是在有最後期限的情況下？
this entry was posted in 心得體會 and tagged artima, 債務, 編碼. bookmark the permalink.
搜尋技術上的李彥巨集
1997年2月李彥巨集提交了超鏈分析的專利申請 1998年4月李彥巨集赴澳大利亞演講搜尋前瞻技術，其中聽眾席上就有佩奇和布林 1998年10月 google上線，同年申請了pagerank的專利，但由於pagerank與李彥巨集之前申請的超鏈分析專利具有相似性，美國專利商標局2001年9月才獲准了p...
技術債務可能是這樣來的
看我技術部落格的朋友可能有注意到，最近更新了一系列與cef ppapi skia相關的文章。在研究它們的過程中，有一些有意思的經歷，非常典型，可以從乙個方面解釋 技術債務 的由來。接下來我會講講這次經歷，並從此展開，看看形成技術債務的原因及應對策略。因為業務需要，我得在ppapi外掛程式中顯示另乙個...
區塊鏈錢包技術上怎麼實現 區塊鏈錢包的技術原理
區塊鏈錢包實現的技術原理用一句話表示就是 錢包助記詞生成了種子，種子發芽結果，果實就是私鑰，私鑰推導出了公鑰，公鑰資料的節選部分成了錢包位址。同時錢包提供了key store，他也是私鑰加密後的檔案為了配合正常的密碼使用，便捷使用者的錢包使用。我們首先要清楚幾個概念 1.私鑰 公鑰和位址產生的方法。...