技術債務「技術債務」是開發團隊在設計或架構選型時，從短期效應的角度選擇了乙個易於實現的方案。但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。
簡單的說就是為了快速地解決問題，而採取的不規範的方案。
比如：開發工程師將某個判斷條件寫死、測試工程師未進行深入自動化測試、架構師運用了乙個即將過時的框架。
危害性對於房貸，大家肯定每個月都記著去還。
但是，對於技術債務，大家似乎都不那麼關心。
的確，這個東西不一定誰借誰還，可能乙個人的**中產生了技術債務，可能是由於專案做，工作壓力大，離職了。
那麼，這筆債務就壓在了工作接替者的身上，古人語：父債子償，不知道這叫什麼，o(∩_∩)o哈哈~
比如我們在乙個類中欠下了技術債務，如果對這個類進行擴充套件、修改，或按照原來錯誤的寫法寫了一些新的業務方法。
用不了多久，我們就會發現我們已經無力償還這份技術債務啦，只能重構啦。
客戶：經常bug纏繞，長期缺失的需求不能上線。
運營：不合理的介面設計、文件缺失、系統響應慢。
運維：頻繁的bug修復上線。
管理層：各方的抱怨讓管理層崩潰，尤其是bug、延期等問題。
研發：開發人員的工作比較多面，一方面開發新的需求，另一方面又要維護他人遺留的**。
所有的問題，最終都會回到研發人員進行再次開發、修復，所以 加班，加班，加班...
其實每乙個研發都不願意出低質量的產品，也沒有人願意接受滿手都是坑的**。
分類由於經驗的缺乏導致初級開發者編寫了質量低劣的**。
解決方案：
1.技術培訓
畢竟大部分的程式設計師學習能力還是很強的，部門牛人的培訓還是很有必要的，也是學習的重要途徑之一。
從最開始的**規範、到熟悉業務、最後再到編寫文件。
2.codereview
codereview 是非常重要的，同時也是對自身的乙個提高。
在這個階段不同工程師之間可以相互review,審查別人的**能夠發現很多問題，同時也能學到很多知識。
團隊根據當前而非未來進行設計選型，這種方式可能很快就能解決當前的問題，但卻很拙劣。
這就情況很可能是為了圖省事才這樣幹的。
也有可能是工期太短，人員太少，技術問題等等。
推薦方法必須能夠有效處理當前需求可預見的情況，對於未知的、可能出現的特殊情況，很小的改動就能解決問題。
根據當前的業務，進行合理的建立資料表，盡量的**解耦和。
必須有日誌模組，操作日誌，錯誤日誌，業務日誌等等...
開發前，針對產品提出的需求，進行要進行細節確認，自己也可以畫乙個程式的流程圖。
開發時，首先把流程全部順下來，其中遇到呼叫其他介面、技術難點、需求模糊，及時確認或記錄 todo 標籤。
開發後，及時對自己的流程進行確認，檢視**中是否有未解決的地方。
每個公司都有自己任務管理系統，例如jira之類的，提測後，時時關注自己的bug。
如果與產品有分歧的地方一定要及時溝通，達成共識。
因為有些程式可能需要進行壓力測試，所以伺服器的配置還是很關鍵的。
多個環境的測試，更能保證程式的健壯性。
等產品上線後，開發就沒有那麼緊啦，這個時間大家可以找個時間處理技術債務，一邊建立感情，一邊品味一下原來的**，是不是酸爽無比。
勇於發現系統中的技術債務，當然不是為了所謂的獎勵，僅僅是為了自己的提高，讓自己為系統負責，而不是事不關己高高掛起。
當然，最重要的其實是把技術債務的重要性提到乙個被認可的位置上。
工程師如果能遇見乙個債務可能導致的問題，自然願意花時間去處理。
切記：一些重要的技術債務遠遠比開發新系統的優先順序要高很多。
thanks ~
免費提供技術諮詢服務（自己懂的知識）。
it小圈兒
技術債務？管理債務？
昨天晚上重要客戶再次投訴。這已經是最近幾個月的第三次投訴了！當年為了爭客戶，給客戶迅速開發了跨越三個系統的定製需求。客戶爭到了，這個快速的定製需求就一直當正式工具被用起來。這是第三年了，這個定製功能一直在找麻煩，甚至有可能丟到客戶。昨天晚上是因為其中的乙個系統切換到備份，但是其他系統不認識備份系統的...
讓我們來聊聊Flash 11
let s talk iphone 這是即將發布的蘋果大會廣告語,新版的iphone5預計會在大會上發布,差不多的時間flash11正式版也會發布,so,let s talk flash11.新版的flash11最讓人矚目的特性就是硬體3d加速,並提供一套基於actionscript3的3d api...
我們來聊聊物件導向吧 一
前言 什麼是物件導向,對於初學者其實就是個噩夢,但是其實物件導向,也不可怕,我個人理解是 變數把具有一定作用的資料存起來,以便後面使用,而函式則是將經常使用的功能封裝起來以便後面使用,而物件導向的思想其實把擁有重複使用的變數和函式組裝起來的一種思想,分隔成一小塊塊的 以便管理和日後的維護.繼承 子類...