入職一個月，我在項目中犯了的哪些錯？

趁著今天周末，爬上來總結(jié)一下，入職的這一個月，我在項目中犯的一些錯誤。正好趁著今天人少，小鹿會在文末給大伙送一波書籍。

不知不覺入職都一個月了，這一個月感覺過的賊快而且賊充實，更賊有收獲，你要問收獲是啥？那就莫過于項目中出了各種錯。

我們前端團隊就我一個應(yīng)屆生，算是一個拖后腿的吧，哈哈哈，初次入職，接觸到公司的項目，出錯也是很正常的，但是想要快速的去適應(yīng)以及不再出現(xiàn)一些小錯誤，那就要每天都好好的反思了。比如，晚上躺在床上，想想今天又在項目中得到了哪些教訓(xùn)。

今天就和大家伙聊聊在項目中我犯過的一些比較“智障”的問題。

先說說版本控制 git，玩壞不止一兩次了，每次都要親自叫老大幫忙過來解決，git 基本的操作，我相信各位都玩的很 6 了，但是有一些特殊情況真的是第一次遇到，不敢輕舉妄動呀，不然就該刪頁面跑路了。

畢竟之前一個人，一個項目，怎么玩都沒事，玩壞了大不了重新上傳，但是到了團隊中，git 的版本提交都要涉及到多個人甚至很多人，提交的規(guī)范那也是必不可少的。

舉個實際的例子，之前提交代碼團隊都用的是傳統(tǒng)的提交，每個人將項目 fork 之后，都在自己的分支進行開發(fā)，開發(fā)完成都會提交一個 pr，然后項目負責(zé)人同意后才會進行真正的合并。

但是有個問題，人一旦多起來，整個項目分支就顯的很亂，如下：

這條綠色的就是項目的主分支，而其他顏色的線是團隊中各個隊員的分支，開發(fā)完畢后我們一般都合并到主分支上。

這樣看起來每個人什么時間提交了什么，看起來很費勁，所以有了變基模式（rebase）。多人提交如下：

這么一看，清晰多了，每個節(jié)點就是代表那個人提交了新的代碼，這樣一目了然，而不去之前一堆分支中去找。

初次使用，確實被我玩壞過幾次，但是老大總是很有耐心的手把手教科書本版教我，我的操作問題出在哪，你們可以想象出那種多么有愛的畫面，有這么好的一個老大，誰不愛呢？

關(guān)于 Git 變基后期會專門寫一篇技術(shù)文，這里俺就不多啰嗦了，看下一個問題。

之前寫的項目基本以實現(xiàn)功能為目標(biāo)，代碼的可優(yōu)化性基本不考慮，也就是說，你寫完一段功能代碼，是否考慮一下有沒有更好的更簡潔或者設(shè)計更好的代碼邏輯。

這也算我之前寫代碼的一個毛病吧，入職之后，算是長記性了，老大把我這毛病硬生生的給調(diào)出來了。每次開發(fā)完提交代碼，都需要經(jīng)過老大的審核，會從頭到尾看一下你寫的代碼邏輯有沒有問題，如果有問題會告訴你這個地方應(yīng)該怎么改動，怎么去優(yōu)化實現(xiàn)達到更好的一種格式和規(guī)范。

為了盡量不占中老大幫我審核代碼的時間，每次我自己寫完之后，都要問一問自己代碼有沒有可以優(yōu)化的地方，自然而然形成了一種習(xí)慣。

除此之外，之前開發(fā)工具中中沒有裝 ESlint，難免少一個分號，都會被老大挑出來，然后改完進行重新提交?？粗娇赡芎芏嗳藭f，你們代碼都這么規(guī)范標(biāo)準(zhǔn)的嗎？

我個人覺得，越是這樣嚴格的要求，越是好，偶爾聽到朋友那公司項目代碼爛成一鍋粥，突然發(fā)現(xiàn)自己有多么很幸運啊，很幸運能遇到這么規(guī)范的代碼設(shè)計。

這也看得出，我們老大也是一個對團隊隊員嚴謹和高標(biāo)準(zhǔn)要求的一個人，所以能在年輕的時候多遇到一些老大這樣的人，無論是技術(shù)還是生活，對我還是有很大影響的。

除了以上項目中出現(xiàn)的問題，還有比如說第三方庫的使用標(biāo)準(zhǔn)以及代碼提交原子化，變量和方法的規(guī)范命名等問題，作為職場新人，還是應(yīng)該多多注意的。

一個月的時間，總結(jié)了很多實際項目的經(jīng)驗，我覺得這些經(jīng)驗都可以拿出來分享，少走一些坑，多一些方法，這對與剛接觸一個陌生的項目是很有幫助的。

后邊正在準(zhǔn)備一篇入職如何快速融入熟悉項目的經(jīng)驗總結(jié)。一起期待吧！

—?【 THE END 】—
本公眾號全部博文已整理成一個目錄，請在公眾號里回復(fù)「m」獲取！

3T技術(shù)資源大放送！包括但不限于：Java、C/C++，Linux，Python，大數(shù)據(jù)，人工智能等等。在公眾號內(nèi)回復(fù)「1024」，即可免費獲?。?！