湊合
在日常開發中，使用或者測試中出現問題，一般都喜歡打補丁，補丁這個概念被用錯了。補丁不是湊合。補丁不是簡單粗暴，毫無業務邏輯性的湊合。
如果為了修復一個問題，而讓你的程式碼變得不能體現或者表達它的業務含義或者汙染了現有的程式碼邏輯，那麼這個修復就埋下了一個日後潛在的更大的問題。
為了清晰性，為了功能的單一性，為了以後的可維護性，程式碼不能湊合。
陋習舉例：比如業務調整，需要呼叫端新傳入一個引數，但是為了省事，正好方法中有另外一個暫未使用的引數A，此時使用A來表示新增的引數，而A的引數名完全不是那個意思。

軟體開發前提取並搞清楚核心領域物件
如果讓你實現一個功能，包括增刪改查，那麼你非常清楚這個核心領域物件是什麼嗎？它業務含義是什麼？什麼是這個核心領域物件的屬性？或者說這個核心領域物件包括的屬性有哪些？
討論需求的時候，也是如此，都要搞清楚或者把關注點放到核心領域物件建模和理解上。
比如，概念和術語都是什麼含義等等。

應該給自測更多的時間和更多的關注
軟體開發對過程中對於出現的設計或者開發問題，我們可以花費大量大量時間來排查，甚至推翻重來，那麼為什麼開發完成不進行好好自測，在自測上花點時間也能讓你更加熟悉業務，因為看問題的角度變成使用者，因此自測時間要充足這個是值得的非常值得(多使用幾個用例流進行測試)