本文純粹個人意見，有些偏執(zhí)，不喜勿噴~

owner意識

首先要在意識上理正，代碼是你寫的，你要為你寫的代碼負(fù)責(zé)，質(zhì)量不好都是代碼編寫者的問題，沒有借口。是QA同學(xué)沒有測到位？是相關(guān)信息沒有同步給你？是需求溝通不明確？是時間太緊張？拉倒吧……就是沒有擔(dān)當(dāng)！

bug是無法杜絕的

這是典型的給自己開脫的借口，打印“Hello world”到控制臺，為啥可以做到?jīng)]有bug？因為這個邏輯簡單？而你要實現(xiàn)的邏輯復(fù)雜？呵呵...

理清業(yè)務(wù)

要實現(xiàn)的這塊功能邏輯到底是什么樣子的，會影響哪些，會被哪些影響，依賴的系統(tǒng)可能出現(xiàn)什么異常，用戶或上層代碼可能會怎么使用，先把正常行為走通，很多情況都是因為業(yè)務(wù)都沒有理清就去編碼，不出問題才怪

異常處理

這個是有個度的，需要衡量折中，二八原則，搞定常見的異常情況就可以了，用戶一輩子都不會走的異常路徑，不搞問題也不大。當(dāng)然，安全問題要足夠重視，已知安全問題必須全部修復(fù)，安全無小事

自測落地

不要因為后面的流程中有QA幫忙測試就懈怠了自測。線上出bug，丟人的還是你。告訴你個消息，有些公司，其實是沒有QA這個崗位的。

關(guān)于單測

有些人一提自測，就來單測覆蓋率云云，不得不承認(rèn)，TDD的方法編寫代碼，單測確實必不可少，但，這只是通往羅馬的其中一條路，不是只有這一條路。

所以，衡量質(zhì)量，單測覆蓋率個人覺得不重要，重要的是QA給你測出多少bug，上線之后用戶幫你測出多少bug，一個單測不寫，QA和用戶都沒有測出問題，那你就是牛逼，單測覆蓋率90%，用戶還是用出各種問題，這個單測寫的就是浪費時間，請用結(jié)果衡量。

實話講，個人是不寫單測的，因為寫單測太慢，測試的范圍太窄，直接測業(yè)務(wù)邏輯，只要業(yè)務(wù)邏輯OK，從前到后說明都沒問題，效率高得多