每個人都有壞習慣，畢竟金無足赤人無完人。

但作為一名開發人員，壞習慣會嚴重損害工作效率，還會影響周圍的人。

[[283239]]

杰克·坎菲爾德曾說：“習慣決定未來”。想成為一名真正的開發人員，就必須要改掉壞習慣。如果做到了，那么工作也就會事半功倍。

接下來，讓我們看看有哪些你需要盡快改掉的壞習慣。

不懂拒絕

首先我想說，答應別人的請求是一種謙遜而無私的行為，這說明你愿意付出自我，幫助他人。

但是如果什么都答應，那就會降低你的效率。一天到頭，你還得一個人默默地敲代碼。

我不是說不應該幫助其他開發人員，我的意思是，不要讓幫助他人降低你的效率。一些開發人員喜歡問很多問題——遇到一點小事就要湊到你跟前尋求幫助。

對此，保羅·科埃略說得很到位：

當你“答應”別人的時候，記住也不能“拒絕”自己的正事。

如果你覺得自己不擅長拒絕別人，可以讓他們只在特定時間來找你——讓自己有一些“集中”的時間來完成工作。

這也會讓他們開始自己尋找解決辦法，而不會盲目地來找你幫忙。如果他們實在想不出來，可以把問題寫下來。這樣他們來找你的時候，可以直接問你所有的問題。這種方法可以讓其他人只打擾你一次，而不是每有一個問題就要打擾你一次，因此可以極大地提升你的工作效率。

你認為“完成”了的工作可能并沒有“完成”

開發人員對于“完成”這個詞的定義與其他人不同，因為開發人員還有大量潛在的事要做。例如，在一個節奏很快的團隊里，開發人員也想要快速地完成工作。他們的工作有嚴格的時限，感覺一分一秒都不能浪費。

雖然對于“完成”的定義不同，但是完成工作絕不僅僅是為了一個有趣的功能寫完一頁代碼。每次你覺得工作做完了的時候，你要想想以下問題：

你重構代碼了嗎?你有仔細研究自己的代碼，并且確保其他開發者也能理解嗎?如果有任何一個問題的答案是“沒有”——趕緊完成它!

還有歸檔呢?這個功能是否需要歸檔?你有告知測試人員要如何測試這個功能嗎?有什么條件是開發人員需要事先知道的?

告知測試人員要如何測試一個功能會節省你很多時間。

你知道嗎，根據加州大學研究數字分心的格洛麗亞•馬克的說法，在被打斷之后，平均需要23分鐘才能再次投入到工作中。

你需要問自己的最后一個問題：你測試自己的代碼了嗎?這個測試可不是簡單的基本邏輯測試。說到測試，我們可以看看下一個壞習慣。

從不測試自己的代碼

當一名開發人員，最棒的時刻肯定不是測試。大多數開發人員在測試自己的代碼時，都十分懶惰。他們可能也就只做一做基本邏輯測試。

但這個壞習慣會讓你在交付功能時花更多的時間。如果不測試你的代碼，測試人員可以在一分鐘內找到一個漏洞，如果你自己測試，完全可以避免。

測試人員每報告一次漏洞，你就要重復一遍代碼。另外，你修補了漏洞后，測試人員還得重新檢查一遍。這就很不劃算。你可能會說：

“但測試會增加我的開發時間。”

不，它不會。這是一個常見的誤解。測試只會在工作初期增加開發時間，因為你還沒學會正確地測試代碼。當你習慣了之后，測試就會成為你開發過程中的一部分，變成一個非常好的習慣。測試可以省掉很多時間以及潛在的麻煩。

設置過大的操作指令

一個非常低效的習慣是設置過大的操作指令。太大的操作指令會讓你過度注重一些細節而忽視整體規劃。這些指令會發生大量變化，最后你自己都不知道發生了什么變化。

另外，如果讓你去審閱一個有100多份變更文件夾的指令，你會怎么想?你可能想罵人，也可能完全失去了審閱的動力。

小的操作指令才是合適的。它們讓開發者可以給出一個詳細的指令信息。但“還要優化一下”可不算詳細的指令信息。

小的指令也可以讓代碼審閱更加輕松。審閱者可以一次審閱一種變化，并了解開發者的思維過程。

小的操作指令也更容易調試。開發人員可以輕松回到某個指令，然后測試是否有漏洞。小指令的好處就是，當你發現了漏洞的來源后，你無需檢查太多代碼。

小代碼會讓你的工作更有效率，事倍功半。

努力擺脫這4個壞習慣，成為超級賽亞人，pei，成為超高級碼農吧~