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