想要練就優秀的編程技術組合需要數年的試錯經曆。幸運的是，現在有一(yī)些小(xiǎo)方法可以幫助你很快成爲更優秀的程序員(yuán)和更好的團隊成員(yuán)。

嘗試破壞寫出的代碼

你有責任親自測試自己寫出的代碼。公司是否擁有出色的質量檢查團隊并不重要，關鍵是你要對自己的代碼負責。在公司工(gōng)作的每個人（無論是軟件開(kāi)發人員(yuán)還是測試人員(yuán)）的目标都應該是盡快交付高質量的軟件。打造出色的産品需要整個團隊的合作。

如果不測試代碼，那麽測試人員(yuán)肯定會發現你的錯誤。他們會創建故障票，你修複好故障功能後，将故障票發回。但是如果還存在問題，就還會收到故障票。這樣可能會陷入無止境的錯誤循環，雙方都在浪費(fèi)時間和耐心。仔細測試代碼則可以減輕所有人的痛苦，這是你應該始終做的事。

這可能是一(yī)個微不足道的變化，但最好還是先測試下(xià)自己的代碼。編程很複雜(zá)，很可能你忽略了一(yī)些東西。沒有程序員(yuán)不會犯錯，隻需花幾分(fēn)鍾進行測試就能節省每個人的時間。不管怎麽想，請測試寫出的代碼。如果發現錯誤，就編寫單元測試以避免将來出現此錯誤。

請放(fàng)下(xià)驕傲并嘗試破壞你編寫的代碼，測試你可以想出的所有不同方案。尋找邊界情況。你了解自己的代碼應該做什麽以及它應該做什麽，因此你就是測試代碼的理想人選。

進行小(xiǎo)型提交和拉取請求

提交到版本控制存儲庫以展示代碼的曆史記錄。每個人都應該留下(xià)一(yī)條有意義的消息，說明進行提交的原因。雖然能夠像書(shū)一(yī)樣閱讀提交曆史有點費(fèi)力，但是對于試圖了解發生(shēng)了什麽的人來說，提交曆史應該是可讀的。

要做出好的提交，必須将每次提交的範圍縮小(xiǎo)。這樣你每次提交的重點就會放(fàng)在功能、錯誤修複和重構等微小(xiǎo)的細節更改上。如果提交的内容太大(dà)，則無法在簡短的提交消息中(zhōng)對其進行描述，因此代碼曆史記錄将變得更難以閱讀。

小(xiǎo)型提交還具有其他優點，它們更易于測試，并且如果測試失敗，也方便調試，因爲導緻該錯誤的代碼更少。小(xiǎo)型提交也更容易還原到較早的提交，因爲這意味着在還原時損失的代碼更少。

發出拉取請求時，應遵循相同的規則。縮小(xiǎo)拉取請求可以使審閱代碼的人員(yuán)更徹底、更确定地執行代碼。長達數千行并更改數十個文件的拉取請求将不會得到仔細檢查。如果不檢查拉取請求，最終會得到較差的軟件。而且，如果别人不審閱你的代碼，你将不會獲得任何反饋，這會阻礙你的成長。

快速構建，然後重構

編程是一(yī)個複雜(zá)的過程。要成爲高效的軟件開(kāi)發人員(yuán)，需要以有組織的方式解決問題。在編寫任何代碼之前，應該考慮一(yī)些對于當前來說比較關鍵的幾個方面。

你想達到什麽目的？你确定自己完全了解要求嗎(ma)？花幾分(fēn)鍾時間思考需求可以節省大(dà)量時間。同時還應該确保在項目中(zhōng)（或者正在研究的另一(yī)個項目中(zhōng)）尚未解決此問題。許多功能都是相似的，那些可以使用的經過驗證的代碼也許可以直接拿來用。最後，必須提出一(yī)些解決問題的方法。

思維固然重要，但小(xiǎo)心别陷入過度思考的陷阱。當對目前存在的解決方案有所了解時，請選擇最有前途的解決方案并開(kāi)始編碼。不要試圖讓代碼無懈可擊，也不要嘗試處理所有極端情況，隻需完成代碼的關鍵部分(fēn)即可。

代碼的第一(yī)個版本不可能是最後一(yī)個版本。即使盡力而爲，也必須假設解決方案存在缺陷。也許它運行緩慢(màn)、難以閱讀或依賴過多的外(wài)部庫。無論是什麽，都必須重構。

删除重複的部分(fēn)，尋找更抽象的版本，并在必要時添加注釋。創建一(yī)些單元測試，以便可以自信地重構基本功能。還需考慮代碼是否可能破壞應用程序其他部分(fēn)的内容，并且将變量名稱更改爲其他人可讀。

盡一(yī)切努力創建盡可能好的代碼，這就是成爲優秀程序員(yuán)的所有要求。