程序員發展十分重要的12條平常習慣

 

（1） 代碼簽入要填備註：基本到基本的一條原則，好處不言自明，尤爲是當團隊成員較多的時候，清楚的註釋可以快速定位一些因交叉簽入和測試不完全形成的bug。尤爲要註明多個版本同時更新時的同步信息，儘可能保證關鍵信息，如版本、bug號等的完整。

 

（2） 簽入代碼前請先獲取最新的版本：很容易被忽略的一點，由於頗有可能你的同伴也在修改同一個文件，此時，若是你沒有獲取最新的代碼，就匆忙地簽入，是很是有可能在比較版本的時候漏掉衝突的地方，而直接簽入的，致使同伴的代碼被覆蓋。

 

（3） 簽入代碼先後均要對功能進行驗證：嵌入前必須保證代碼的正確性，這個不用說，嵌入後，從新獲取版本，再次編譯並驗證，有的時候是很是重要的，這樣能夠避免咱們由於簽入失誤形成的問題，同時，這也是爲了保證服務器上的代碼是正常可編譯的。

 

（4） 及時彙報本身的工做進展狀況：咱們能夠天天早上把今天的工做作個簡單的計劃，而後在下班前把今天的工做內容作一下小的總結，並抄送給領導，不少時候由於不知道要寫啥，或者可能一句話就能說清楚，咱們就不肯意去作這個簡要的彙報，有的公司會要求你們每週作彙報，但本身仍是以爲天天有個開始和總結，不只可以讓本身對任務更加清晰，同時也能夠增強本身和領導間的溝通，何樂而不爲呢？

 

（5） 修改公共代碼後請進行全面測試：這個也是毋庸置疑的，由於公共代碼牽扯的內容可能不少，若是咱們只測試咱們預期效果的那部分功能的話，頗有多是正確的，但其餘地方可能就會出現問題！這個概率是很是高的，因此建議咱們可以慎之又慎地修改公共代碼，若是沒有把握，請儘可能經過複製功能代碼的方式來經過增長冗餘，避免影響其餘內容。

 

（6） 動手編碼前請先和相關人員再次確認需求或bug詳情：不少的問題其實改起來並不麻煩，可是若是要是由於理解的不一致形成的改來改去，這個是最折磨人的，因此，必須雙方都徹底確認後，再動手！切忌不要擅做主張。

 

（7） 常常主動地去和別人進行Code Review：有不少咱們固有的不良編碼習慣，或者一些咱們不熟悉的內容，這些都是咱們很難觀察到，但咱們的同伴可能一眼就能看到的地方，有交互纔會有學習，多去理解和學習同伴的好的編碼習慣和思考方式，對咱們來講這是最容易的一個途徑。

 

（8） 永遠不要輕視本身手中的工做：這就像一條充滿魔法的詛咒，沒有人能逃脫它，因此，千萬不要由於輕視一件任務，而延時去作它，不然你會加班到很慘。

 

（9） 不要偷懶去拷貝代碼：如今不少的代碼都是咱們拷來拷去，可是，所以而遇到的不少問題又多少次讓咱們幾乎抓狂？拷代碼不但不能增長咱們對代碼的理解，仍是引入錯誤的一個主要來源。必須明令禁止！

 

（10） 在對工程進行改動前，請先確保該功能點已經能夠正常工做：很簡單，不要隨隨便便在項目中直接修改功能，尤爲是一些新的功能，請先在本身的示例工程中先保證功能的正確性，而後再進行移入，這樣會給咱們節省不少的時間，不信你試試！

 

（11） 合理安排工做中的「空閒」時間：所謂「空閒」時間，即在不一樣項目間或者是在同一個項目不一樣階段之間的短暫的中場休息時間，還有就是當項目後期，集中處理bug的時候，可能會偶爾出現的一些工做真空期，這個也算是作軟件行業的一個常見狀況，時忙時緊。的確，咱們能夠充分利用這些時間來休息，可是若是咱們能稍加利用，則會讓咱們有更大的進步，好比研究一下一些系統中的疑難雜症，學習一些新的技術，看看管理方面的書籍，最差勁還能夠看看別人寫的代碼長長見識。

 

（12） 記錄工做中的點點滴滴：所謂聚沙成塔，再大的成就也是一點一點攢起來的，咱們的我的發展也一樣離不開這個原則，對於咱們平常遇到的一些技術難題，管理經驗，甚至是本身的心得體會，若是可以記錄下載，甚至慷慨地拿出來和你們分享，那咱們將收穫更多意想不到的東東。

 

    目前，本身就想到這麼多，本身雖然也還沒有所有作到上面所述，但也正在努力中，這裏權做記錄，以提醒本身，但願能對你們有所幫助。