范冰冰的偷稅漏稅案有了判決結果，她被罰款 8.8億
無論是演藝圈的大佬，還是我們技術圈的碼農，出來混遲早要還的。
本文將比較IT人欠的技術債和范冰冰欠的鉅額罰款的相同點和不同點，和對如何避免技術債提出三點建議。
1. 什麼是技術債？
據作者的不完全統計，除了需求變更，程序員還經常吐槽的另外一件事，就是接手了一個沒有文檔的半路項目。
更鬱悶的是，前面負責開發的人還離職了，找不到人。
更加更加鬱悶的是，這個半路項目的代碼完全就是一大盤意大利麵條——完全看不出頭緒。
意大利麵條式的代碼是技術債的一種明顯的體現形式。
還有的技術債沒有這麼明顯，比如架構設計/技術選型方面的不足。
百科對技術債的定義如下:
技術負債（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、代碼負債（code debt），是編程及軟件工程中的一個比喻。
指開發人員為了加速軟件開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟件開發的方案，從而在未來給自己帶來的額外開發負擔。
這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。
軟件工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用，或是進行重構，把架構改善為最佳實現方式。
2.技術負債和偷稅罰款有什麼異同？
1
相同點一: 對產品危害巨大
大家都在討論范冰冰被罰的8.8億是多麼鉅額的罰款，這裡我想指出她更大的損失則就是她作為國內一線女星的品牌價值。
品牌價值的損失可能給產品造成致命的一擊，如果這個人是在政法領域，可能就直接被“下課”了。
即使不在政法領域，這樣的劣跡也足以讓製片人/廣告主退避三舍。
技術債給軟件產品的危害，就如同上面的百科的定義裡寫到的，當技術負債積累到一定程度，後續的維護成本和開發成本會急速上升，嚴重的情況整個軟件都要重寫，比如當前的架構/數據庫已經無法滿足業務增長帶來的性能挑戰。
2
第二個相同點，就是技術債和偷稅漏稅罰款一樣，欠的債隨著時間的推移，需要加倍的償還。
范冰冰其實並不是漏稅漏了8億，而是漏稅在法律上需要加倍償還造成的。
另一個例子，日常生活中，為了省幾十塊的停車費隨便停車，要罰款500塊到2000。
技術債也是一樣，今天節省了幾天的時間快速把功能實現了，隨著產品迭代，產品規模越來越大，如果架構設計不良，要做局部的修改都會牽一髮而動全身，開發和維護成本巨大，欠的債要加倍償還。
3
第三，技術債和偷稅漏稅的不同。
偷稅漏稅是一點也不要有，但是技術債並不是完全不能接受。
大家可能覺得技術債是越少越好，其實也不是。
持續將技術債維持在很低的水平需要較大的投入。所以這是一個投入產出比的問題。
比如一個創新的搶佔市場，或者獲得先機對成敗至關重要的產品研發，它的時效性就更重要。
還比如一個生命週期相對較短，可以預見的產品，技術債的水平也需要做最優投入產出比的確定。
比較完了這兩者的異同，現在我們來看一看：
3.如何避免欠下技術債？
1
第一步，你要知道你自己欠了多少技術債。
如果有條件的話，可以請技術專家來幫忙做一下評審。
如果沒有條件，可以使用工具來檢測自己的技術債的水平，比如Sonar。工具檢測的結果僅僅做參考，這方面主要還是靠人來尋找自己主要的技術債的焦點，然後解決焦點問題。
再次強調一下，工具可能發現不了真正重要的技術債焦點，所以不要過度依賴和迷信工具的判斷。工具只是一個起點，不是終點。
這裡我要特別提醒一種比較特殊的技術債，就是安全漏洞。
在有的行業當中，比如：
- 金融；
- 涉及到關鍵用戶信息的行業如酒店業；
- 涉及公司商業機密如公有云服務，
在這樣的安全關鍵的行業中，我就不會把安全漏洞認為是技術債，因為在這樣的環境中，安全漏洞不是可以欠的債，而是壓根兒就不要借這個款。
如果發現安全漏洞的話，要立即修復。
其他行業，對安全漏洞的處理方式略有不同，需要視情況處理，不能一概而論。
2
第二步，考慮在你的團隊創建一份大家達成一致的代碼規範，並且開始遵循。新加入的團隊成員也不例外。
代碼規範不一定是要非常的全面和長篇大論，你們可以從最基本的開始，比如命名規範，註釋規範，對異常處理的規範等等。
代碼規範最好由研發團隊和測試團隊（尤其是也做白盒測試的測試團隊）自行進行討論後得出，而不是隨便從網上下載一個規範就開始實施，那樣可能會不適用當前情況，比如不符合團隊習慣，或者規範過於重。
3
第三，考慮採用同行評審。
這一點比較好理解。但是實施方法可輕可重。
比較重的就是直接形成簽入流程，工具上走代碼評審的流程後才能簽入。我之前做一款全球級的在線服務的自動化測試的時候，自動化測試代碼簽入都是要走流程。
還有一種我在一家大型互聯網公司看到的做法，就是定期組織團隊的代碼評審，這個代碼可能是已經簽入甚至發佈了的代碼。有點類似研討會，大家在一起評審代碼，一起學習和進步。
4
第四，重構
有的團隊會定期做重構，有的團隊因為各方面的原因沒有這麼做。
重構是一個修整的動作。如果是一個在管理技術債方面沒有太多經驗的團隊，我建議可以按照上面的這三步的順序開始著手，先解決焦點問題和預防技術債繼續堆積。
好了，現在做一個小結：
技術債是對產品有害的，它會隨著時間的推移不斷地積累和擴大不良影響。
技術債不是越少越好，需要按照具體的行業情況和要求來管理。
在某些信息安全關鍵的行業中，如金融，酒店，公有云服務，安全漏洞不是可以欠的技術債，一旦發現需要立即修復。
最後有四點避免欠下技術負債的建議:
第一步，你要知道你自己欠了多少技術債，著力解決焦點問題。
第二步，考慮在你的團隊創建一份大家達成一致的代碼規範，並且開始遵循。新加入的團隊成員也不例外。
第三，考慮採用同行評審。
第四，重構。沒有形成定期重構習慣的團隊，可以先從上面3點開始做起。
你對范冰冰的判罰怎麼看，你又是如何看待技術債的? 歡迎再留言區留言~
閱讀更多 熱愛代碼勝過愛我自己 的文章
