需求分析負債 不懂需求分析的軟件開發工程師不是好的軟件開發工程師，遇到問題一定要與上級領導或者客戶及時反饋，及時 溝通，某些需求不能做就是不能做，要持有一種質疑的心。找正確的途徑去反饋問題而不是背地裏去發惱騷，要 懂得有效的溝通方式，讓客戶或者是領導理解技術實現痛點。如果軟件開發工程師沒有理解好項目需求而盲目開 發項目，必然導致領域業務與開發業務不匹配， 從而付出更多的時間與精力去開發項目
開發文檔負債
（1）項目沒有制定開發文檔。沒有制定代碼規範文檔，接口文檔等相關技術文檔。光看代碼不看文檔就夠辛苦了，即使語義化變量 名與函數名，也難易快速理解。（少見）
（2）項目沒有更新開發文檔。項目開發初期還有文檔，後來文檔沒有對應沒有更新，因爲有些需求幾乎都是臨時新增的，導致後期 項目迭代的時候就造成大量的冗餘代碼。（常見）
軟件開發文檔是項目最系統最全面的反映，看文檔比看代碼更容易理解項目的功能模塊。
測試文檔負債 體現於軟件測試覆蓋率低，測試用例不足。 在大多數的企業中，爲了控制人力成本，軟件測試都是由軟件開發工程師去完成，而不是由專業的軟件 測試人員去負責，這樣做往往會忽略了一些軟件漏洞（當局者迷，旁觀者清），也給技術債埋下了更多 的種子。一個企業如果不重視軟件測試的話，做出來的軟件項目絕對是一個不合格的產品。
文檔負債 背景技介術債紹 架構負債 前期項目架構評估不夠充分，導致項目組織不合理，軟件耦合度高，後期項目難以拓展與維護。 正所謂牽一髮而動全身，業務需求不斷新增，軟件項目很難迭代，稍有不慎就容易出現漏洞，後來發現 代碼沒法改，不得不推倒重來，重新開發項目。
編碼負債 編碼質量不高，導致開發團隊難以協同工作。
當遇到軟件產品迭代就會出現一堆技術債，軟件產品更是漏洞百出， 難以維護。
體現在以下幾個方面 ：
（1）代碼命名規範：代碼命名沒有規範，存在大量雜亂不堪的命名代碼。
（2）代碼複雜度：條件語句過多，流程控制過於複雜，代碼嵌套過多。（常見回調地獄）
（3）代碼耦合度：代碼中參數，類，接口高耦合，需要大量修改代碼。
（4）代碼行數：存在大量未使用的代碼。 良好的，統一的編碼規範更好維護以及迭代項目，有利於代碼的重構，一定程度上減少技術債。
業務負債 經常採用投機取巧方案修補漏洞。
沒有深度思考自己業務邏輯代碼或者是沒有徹底理解漏洞產生的原因， 通過簡單的，過多的條件判斷就修補代碼漏洞，或者是強制修改數據庫的用戶數據。這種救得了一時,救 不了一世方案不可取，只造成更多的技術債。
代碼負債 背景技介術債紹 工期負債 項目期限也是技術債產生原因之一。
現在的項目正如馬士兵老師說的那樣，現在的項目趕緊做，做完之後趕緊拿 錢，說白了就是賺快錢。企業爲了搶佔市場佔有率，必然想短期出產品，因此軟件開發工程師必然只能沿用一些 管理負債 老解決方案，加快想項目開發進度。開發出來的產品質量和以前沒有太大區別，軟件生命週期短。
人員負債 一個人員流動性大的開發團隊導致項目開發難以開展或者是開發進度緩慢，再加上團隊中的開發人員能 力不盡相同，各有各的風格，即使規範了代碼風格，但每個人的代碼實現思路也不盡相同。技術債也隨 着人員流動而加大。
協同負債 有兩種以下值得注意：
（1）管理者必定充分認識自己的定位，該做什麼就做什麼，不要過分干涉組員的工作，但要監督組員工作質量。
（2）管理者必定認真分配組員的開發任務，分工明確，各盡其職，避免重複開發模塊。
成本負債 項目的軟硬件環境配置決定項目的成本負債。控制好成本負債纔可以獲得更多的收益。聰明的管理者絕 不會貪小便宜，只顧眼前的成本利益而造成更大的陳本負債，該花錢的地方就有花，不要節省。