做技術工作這麼多年，面臨一大困惑，並不是遇到了不能突破的技術，或者無法解決的難題。而是如何處理技術債務。
這些年，在業務強力驅動的大背景下，隨着項目和迭代的深入，都會陷入越來越多的技術債務，即使我天天強調架構設計的必要性，代碼質量的重要性，但是在我所在的團隊裏，不少同學面對債務的時候都選擇了“先湊合上，以後再改”。
想必做業務開發的同學是能感同身受的，能正常排期已經很不錯了，更別說不少項目還需要倒排，大家開始保守和折中，經常會聽到“不敢動，一動過去的項目可能會受到影響” “感覺問題很複雜，要改的代碼會有很多，這次改不完，要不下次吧” 。
聽下來，似乎很有道理，但是如果仔細分析，還是有解決方案的。
在風險可預知、可控制的情況下做改動，比風險不可控的情況下突然某一天爆發當然要好的多。很多問題是不能拖的，我們總想保證眼前的事情不出問題就好，但是代價就是不斷的貽誤戰機，等後續控制不住的時候，更來不及了。所以，我們需要對問題進行排優先級，優先級高的問題，無論如何都要立刻解決。
在時間有限的情況下，當然不可能什麼問題都去一次性解決好，正確的選擇是控制範圍，抽出精力去高質量的完成一部分工作，而不是把所有工作都低質量的完成。低質量完成的這部分，後續很可能需要花2倍乃至3倍的時候來修復它。
以我過去十多年的經驗，我可以負責任的說，“以後再改”或者“下次再說”，只會有兩種結果：
1. 項目處於開發階段，雖然大家都想把系統做得更好一些，但是團隊成員都陷入大量的新功能開發中。
2. 項目處於穩定階段，現在時間空出來了，但是在線上跑得似乎挺好，有時間做去重構或者加強，還不如把時間放在開發新項目中。更別說了，改壞了，口誅筆伐不會少的。
要想回過頭來把一件事做好的難度，遠遠大於重新做一件事情。
以後再改=不改
下次再說=免談
所以，今天的事情今天做。
描二維碼或手動搜索微信公衆號【架構棧】：ForestNotes
歡迎轉載，帶上以下二維碼即可
點擊“閱讀原文”，所有【架構棧】近期的架構文章彙總
↓↓↓