提及“債”,人們首先映入腦海的應該是“欠賬還錢”的概念。確實債的種類通常如我們日常所了解的:銀行貸款、企業債、個人債等,但還有另一種形式的債,會讓很多程序員和科技公司們苦不堪言。這種債務,欠的不是錢,但是值不少錢,它叫技術債。

　　技術負債的概念首先由沃德·坎寧安提出,他將技術的復雜比作為負債,簡稱技術債。技術債的意思是就是做技術開發的時候欠下的債。在軟件開發過程中,程序員將寫好的代碼直接提交,意味著欠債的開始。在不準確的代碼基礎之上所花的每一分投資成本,都算是技術債的應付利息,不穩固的代碼始終作為一個隱患而最終引發更大的債務負擔。

　　明白了技術債的概念之后,我們或許可以繼續探究下技術債是怎么形成的。首先根據軟件開發的過程來分析,技術債的類型可大致分為三種。

　　第一,文檔負債。在軟件開發過程中,要首先根據市場做用戶需求分析,根據市場需求而制定項目開發文檔,并及時根據需求變化而更新開發文檔。更重要的是,開發文檔作為代碼編程的基礎和依據,應當保持實時同步,以免導致后期項目迭代的時候就造成大量的冗余代碼。其次,更要提前做好軟件測試文檔,保證軟件測試的覆蓋率及測試用例的充足。

　　在這一過程中,任何一個環節都要做到安全有序,任何一個因素有所差池都有可能最終導致技術債的形成。

　　第二,代碼負債。代碼負債的產生多是由于前期項目架構評估不夠充分,或者編碼質量不高,導致項目組織不合理,軟件耦合度高,開發團隊難以協同工作,后期項目難以拓展與維護。另外,對已經產生的技術性問題,部分企業公司采用投機取巧方案修補漏洞,而沒有深度思考自己業務邏輯代碼或者是沒有徹底理解漏洞產生的原因。

　　第三,管理負債。其中又包括工期負債,和成本負債。工期負債是指企業為了搶占市場占有率,必然想短期出產品,因此軟件開發工程師必然只能沿用一些老解決方案,加快想項目開發進度。開發出來的產品質量和以前沒有太大區別,軟件生命周期短。另外,項目的軟硬件環境配置決定項目的成本負債,而一些企業只顧縮小眼前的成本利益而造成更大的陳本負債。

　　對于技術債是很多從事研發的公司經常面臨的問題,而且更麻煩的是,它有一點和貸款不一樣,就是很多時候直到問題出現才能意識到自己欠了技術債,比如說設計失誤。

　　例如Facebook也有技術債的經歷。了解開發知識的可能知道,Facebook最初是用PHP語言寫的。而當年隨著用戶數據不斷革新發展而慢慢出現了一筆寫在PHP代碼里的技術債,且已經到達了無法承受的借債成本。最后Facebook團隊直接發明了一個虛擬機,叫HHVM,因為他們最后發現修復那個漏洞的成本還不如發明另一套新工具。

　　而從另一個方面去看待技術債的話,其實它不一定是個絕對要規避的事物,有時候,一個項目拖不到更好的方案時,需要貸這樣一筆技術債來加速一下進程,盡快上線讓它運轉起來也是有必要的。這就類似于常見的企業債,雖然它的存在會有很大的債務風險,但同樣也會推動企業的快速發展。

　　從宏觀經濟發展趨勢看我國總體債務體量巨大,根據IIF公布的數據,2019年中國整體債務水平已經超過GDP的300%。這顯然看上去并不是一個很良性的發展局面,但其實債務存量引起的社會資本超級巨大,只是大部分被閑置忽視而有待被整合處置。

　　這個時候就需要像阿裡債行這樣的專業債事系統平臺,去依托全球供應鏈、債事資源信息鏈接構建起企業間的債務處理鏈從而激活、變現出巨量的社會資本并將其聚合在一起。

　　技術債其實和企業債從本質上說,不盡相同。如果你傾向于教條式的方法并認定存有債務不好,那你將永遠不會看到你的產品快速地上市。如果你盲目認定債務量越大越好,你也許會得到一個粗制濫造的研發環境或一個漏洞百出的企業架構,從而成為你成功的絆腳石。

　　但是,如果你能始終保持清晰的頭腦,實時轉變思路,勇于接納。但又懂得掌握均衡之道,那么無論是技術債務還是通過阿裡債行這樣的專業解債平臺解決企業債都可以為你的團隊帶來利益或希望。