本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

想要練就優秀的編程技術組合需要數年的試錯經歷。幸運的是，現在有一些小方法可以幫助你很快成為更優秀的程序員和更好的團隊成員。

[[351441]]

嘗試破壞寫出的代碼

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

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

這可能是一個微不足道的變化，但最好還是先測試下自己的代碼。編程很復雜，很可能你忽略了一些東西。沒有程序員不會犯錯，只需花幾分鐘進行測試就能節省每個人的時間。不管怎么想，請測試寫出的代碼。如果發現錯誤，就編寫單元測試以避免將來出現此錯誤。

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

進行小型提交和拉取請求

提交到版本控制存儲庫以展示代碼的歷史記錄。每個人都應該留下一條有意義的消息，說明進行提交的原因。雖然能夠像書一樣閱讀提交歷史有點費力，但是對于試圖了解發生了什么的人來說，提交歷史應該是可讀的。

要做出好的提交，必須將每次提交的范圍縮小。這樣你每次提交的重點就會放在功能、錯誤修復和重構等微小的細節更改上。如果提交的內容太大，則無法在簡短的提交消息中對其進行描述，因此代碼歷史記錄將變得更難以閱讀。

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

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

快速構建，然后重構

編程是一個復雜的過程。要成為高效的軟件開發人員，需要以有組織的方式解決問題。在編寫任何代碼之前，應該考慮一些對于當前來說比較關鍵的幾個方面。

你想達到什么目的?你確定自己完全了解要求嗎?花幾分鐘時間思考需求可以節省大量時間。同時還應該確保在項目中(或者正在研究的另一個項目中)尚未解決此問題。許多功能都是相似的，那些可以使用的經過驗證的代碼也許可以直接拿來用。最后，必須提出一些解決問題的方法。

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

代碼的第一個版本不可能是最后一個版本。即使盡力而為，也必須假設解決方案存在缺陷。也許它運行緩慢、難以閱讀或依賴過多的外部庫。無論是什么，都必須重構。

刪除重復的部分，尋找更抽象的版本，并在必要時添加注釋。創建一些單元測試，以便可以自信地重構基本功能。還需考慮代碼是否可能破壞應用程序其他部分的內容，并且將變量名稱更改為其他人可讀。

盡一切努力創建盡可能好的代碼，這就是成為優秀程序員的所有要求。