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

嘗試破壞寫出的代碼

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

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

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

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

進行小型提交和拉取請求

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

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

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

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

快速構建，然后重構

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

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

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

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

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

盡一切努力創(chuàng)建盡可能好的代碼，這就是成為BAT優(yōu)秀程序員的所有要求。

另外本人是一名CC++的程序員，如果你想更好的提升你的編程能力，好好學習C/C++編程知識的話！那么你很幸運~

分享（源碼、項目實戰(zhàn)視頻、項目筆記，基礎入門教程）

另外，UP在主頁上傳了一些學習C/C++編程的視頻教程，有興趣或者正在學習的小伙伴一定要去看一看哦！會對你有幫助的~

編程學習書籍：

編程學習視頻：