咱們來聊聊技術債務

技術債務

「技術債務」是開發團隊在設計或架構選型時，從短時間效應的角度選擇了一個易於實現的方案。但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。

簡單的說就是爲了快速地解決問題，而採起的不規範的方案。

好比：開發工程師將某個判斷條件寫死、測試工程師未進行深刻自動化測試、架構師運用了一個即將過期的框架。

危害性

對於房貸，你們確定每月都記着去還。

可是，對於技術債務，你們彷佛都不那麼關心。

的確，這個東西不必定誰借誰還，可能一我的的代碼中產生了技術債務，多是因爲項目作，工做壓力大，離職了。

那麼，這筆債務就壓在了工做接替者的身上，古人語：父債子償，不知道這叫什麼，O(∩_∩)O哈哈~

好比咱們在一個類中欠下了技術債務，若是對這個類進行擴展、修改，或按照原來錯誤的寫法寫了一些新的業務方法。

用不了多久，咱們就會發現咱們已經無力償還這份技術債務啦，只能重構啦。

客戶：常常BUG纏繞，長期缺失的需求不能上線。

運營：不合理的界面設計、文檔缺失、系統響應慢。

運維：頻繁的BUG修復上線。

管理層：各方的抱怨讓管理層崩潰，尤爲是BUG、延期等問題。

研發：開發人員的工做比較多面，一方面開發新的需求，另外一方面又要維護他人遺留的代碼。

全部的問題，最終都會回到研發人員進行再次開發、修復，因此 加班，加班，加班...

其實每個研發都不肯意出低質量的產品，也沒有人願意接受滿手都是坑的代碼。

分類

• 無心的

因爲經驗的缺少致使初級開發者編寫了質量低劣的代碼。

解決方案：

1.技術培訓

畢竟大部分的程序員學習能力仍是很強的，部門牛人的培訓仍是頗有必要的，也是學習的重要途徑之一。

從最開始的代碼規範、到熟悉業務、最後再到編寫文檔。

2.CodeReview

CodeReview 是很是重要的，同時也是對自身的一個提升。

在這個階段不一樣工程師之間能夠相互review,審查別人的代碼可以發現不少問題，同時也能學到不少知識。

• 有意的

團隊根據當前而非將來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣。

這就狀況極可能是爲了圖省事才這樣乾的。

也有多是工期過短，人員太少，技術問題等等。

推薦方法

• 系統設計的框架是對的

必須可以有效處理當前需求可預見的狀況，對於未知的、可能出現的特殊狀況，很小的改動就能解決問題。

根據當前的業務，進行合理的建立數據表，儘可能的代碼解耦和。

必須有日誌模塊，操做日誌，錯誤日誌，業務日誌等等...

• 全部的工程師有主人翁的意識

開發前，針對產品提出的需求，進行要進行細節確認，本身也能夠畫一個程序的流程圖。

開發時，首先把流程所有順下來，其中遇到調用其餘接口、技術難點、需求模糊，及時確認或記錄 TODO 標籤。

開發後，及時對本身的流程進行確認，查看代碼中是否有未解決的地方。

每一個公司都有本身任務管理系統，例如JIRA之類的，提測後，時時關注本身的BUG。

若是與產品有分歧的地方必定要及時溝通，達成共識。

• 必定要有健全的測試環境、預發佈環境、正式環境

由於有些程序可能須要進行壓力測試，因此服務器的配置仍是很關鍵的。

多個環境的測試，更能保證程序的健壯性。

• 按期處理一些技術債務

等產品上線後，開發就沒有那麼緊啦，這個時間你們能夠找個時間處理技術債務，一邊創建感情，一邊品味一下原來的代碼，是否是酸爽無比。

• 善於發現系統的技術債務

敢於發現系統中的技術債務，固然不是爲了所謂的獎勵，僅僅是爲了本身的提升，讓本身爲系統負責，而不是事不關己高高掛起。

固然，最重要的實際上是把技術債務的重要性提到一個被承認的位置上。

工程師若是能碰見一個債務可能致使的問題，天然願意花時間去處理。

切記：一些重要的技術債務遠遠比開發新系統的優先級要高不少。

Thanks ~

---

做者：PHP後端開發者

免費提供技術諮詢服務（本身懂的知識）。

關注微信公衆號，留言便可，看到留言後會及時回覆。

IT小圈兒