技術債務
「技術債務」是開發團隊在設計或架構選型時，從短期效應的角度選擇了一個易於實現的方案。但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。
簡單的說就是為了快速地解決問題，而採取的不規範的方案。
比如：開發工程師將某個判斷條件寫死、測試工程師未進行深入自動化測試、架構師運用了一個即將過時的框架。
危害性
對於房貸，大家肯定每個月都記著去還。
但是，對於技術債務，大家似乎都不那麼關心。
的確，這個東西不一定誰借誰還，可能一個人的程式碼中產生了技術債務，可能是由於專案做，工作壓力大，離職了。
那麼，這筆債務就壓在了工作接替者的身上，古人語：父債子償，不知道這叫什麼，O(∩_∩)O哈哈~
比如我們在一個類中欠下了技術債務，如果對這個類進行擴充套件、修改，或按照原來錯誤的寫法寫了一些新的業務方法。
用不了多久，我們就會發現我們已經無力償還這份技術債務啦，只能重構啦。
客戶：經常BUG纏繞，長期缺失的需求不能上線。
運營：不合理的介面設計、文件缺失、系統響應慢。
運維：頻繁的BUG修復上線。
管理層：各方的抱怨讓管理層崩潰，尤其是BUG、延期等問題。
研發：開發人員的工作比較多面，一方面開發新的需求，另一方面又要維護他人遺留的程式碼。
所有的問題，最終都會回到研發人員進行再次開發、修復，所以 加班，加班，加班...
其實每一個研發都不願意出低質量的產品，也沒有人願意接受滿手都是坑的程式碼。
分類
- 無意的
由於經驗的缺乏導致初級開發者編寫了質量低劣的程式碼。
解決方案：
1.技術培訓
畢竟大部分的程式設計師學習能力還是很強的，部門牛人的培訓還是很有必要的，也是學習的重要途徑之一。
從最開始的程式碼規範、到熟悉業務、最後再到編寫文件。
2.CodeReview
CodeReview 是非常重要的，同時也是對自身的一個提高。
在這個階段不同工程師之間可以相互review,審查別人的程式碼能夠發現很多問題，同時也能學到很多知識。
- 有意的
團隊根據當前而非未來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣。
這就情況很可能是為了圖省事才這樣乾的。
也有可能是工期太短，人員太少，技術問題等等。
推薦方法
- 系統設計的框架是對的
必須能夠有效處理當前需求可預見的情況，對於未知的、可能出現的特殊情況，很小的改動就能解決問題。
根據當前的業務，進行合理的建立資料表，儘量的程式碼解耦和。
必須有日誌模組，操作日誌，錯誤日誌，業務日誌等等...
- 所有的工程師有主人翁的意識
開發前，針對產品提出的需求，進行要進行細節確認，自己也可以畫一個程式的流程圖。
開發時，首先把流程全部順下來，其中遇到呼叫其他介面、技術難點、需求模糊，及時確認或記錄 TODO 標籤。
開發後，及時對自己的流程進行確認，檢視程式碼中是否有未解決的地方。
每個公司都有自己任務管理系統，例如JIRA之類的，提測後，時時關注自己的BUG。
如果與產品有分歧的地方一定要及時溝通，達成共識。
- 一定要有健全的測試環境、預釋出環境、正式環境
因為有些程式可能需要進行壓力測試，所以伺服器的配置還是很關鍵的。
多個環境的測試，更能保證程式的健壯性。
- 定期處理一些技術債務
等產品上線後，開發就沒有那麼緊啦，這個時間大家可以找個時間處理技術債務，一邊建立感情，一邊品味一下原來的程式碼，是不是酸爽無比。
- 善於發現系統的技術債務
勇於發現系統中的技術債務，當然不是為了所謂的獎勵，僅僅是為了自己的提高，讓自己為系統負責，而不是事不關己高高掛起。
當然，最重要的其實是把技術債務的重要性提到一個被認可的位置上。
工程師如果能遇見一個債務可能導致的問題，自然願意花時間去處理。
切記：一些重要的技術債務遠遠比開發新系統的優先順序要高很多。
Thanks ~
作者：PHP後端開發者
免費提供技術諮詢服務（自己懂的知識）。
關注微信公眾號，留言即可，看到留言後會及時回覆。
