想想以前剛?cè)胄械淖约海矔?huì)犯類似的錯(cuò)誤。我覺得這些問題挺有代表性的，在這里把這些問題拋出來，大家可以看看自己有沒有犯相同的錯(cuò)誤，及時(shí)糾正可以少走一些彎路。

閱讀代碼

1、閱讀代碼之前沒有先弄清整個(gè)項(xiàng)目的框架

這位新來的小伙伴，一上來就開始看代碼，哪怕我已經(jīng)把相關(guān)的系統(tǒng)設(shè)計(jì)文檔已經(jīng)發(fā)給他了。他沒有仔細(xì)閱讀，對(duì)各模塊的功能也不是很了解。所以，剛開始看代碼時(shí)一頭霧水。

公司里的項(xiàng)目，往往都是很多人一起開發(fā)的。參與公司的項(xiàng)目開發(fā)，無論我們最終分配到負(fù)責(zé)哪個(gè)模塊的開發(fā)，在去專研那個(gè)模塊代碼之前，都很有必要先了解這個(gè)項(xiàng)目的總體框架。這個(gè)項(xiàng)目實(shí)現(xiàn)了什么功能，由哪些模塊組成？哪些硬件模塊？哪些軟件模塊？各模塊之間是怎么交互的？

只有了解了這些，我們?cè)偃プ瞿硞€(gè)模塊時(shí)，能更清楚的知道我們負(fù)責(zé)的模塊要做什么，才能更好地開發(fā)好這個(gè)模塊。

2、閱讀代碼時(shí)沒有把握住主線

對(duì)項(xiàng)目整體框架有一定了解之后，我讓他去看上層的業(yè)務(wù)邏輯模塊，因?yàn)闃I(yè)務(wù)邏輯模塊直接跟產(chǎn)品功能掛鉤，看懂這個(gè)模塊就可以很好地了解我們產(chǎn)品的功能。業(yè)務(wù)邏輯作為最上層的模塊，下面一層好幾個(gè)模塊都對(duì)其服務(wù)，對(duì)其提供了很多接口。

這位小伙伴一開始看代碼時(shí)，從第一個(gè)函數(shù)開始往下閱讀，遇到嵌套好多層的代碼，也一層一層點(diǎn)進(jìn)去閱讀，好像要試圖看懂每個(gè)函數(shù)、每行代碼，最后越看越懵。

我們?cè)陂喿x某個(gè)模塊的代碼時(shí)，盡量沿著這個(gè)模塊的主線去閱讀，沿著主線盡可能快地弄清這個(gè)模塊做的事情。

本模塊可能會(huì)調(diào)用了其它模塊的接口，而且可能還會(huì)嵌套好幾層函數(shù)，我們只要大概知道這些接口實(shí)現(xiàn)了什么功能就可以，先不用一層一層地看、先不要去糾結(jié)其實(shí)現(xiàn)的細(xì)節(jié)。等我們弄懂本模塊之后，日后對(duì)其它模塊感興趣再去仔細(xì)閱讀其具體實(shí)現(xiàn)也不遲。

3、閱讀代碼時(shí)沒有及時(shí)做一些總結(jié)筆記

這位小伙伴全面閱讀某個(gè)模塊的代碼時(shí)，沒有做一些自己的學(xué)習(xí)、理解記錄，這就會(huì)導(dǎo)致看了后面部分，又忘了前面部分。

我們剛開始切入某個(gè)陌生的項(xiàng)目，并且代碼量比較大的情況下，在閱讀代碼的過程中，很有必要做一些閱讀筆記，便于自己反復(fù)閱讀（有些代碼不看好幾遍可能理解得不透徹）的時(shí)候加深一些理解。

做筆記得方式可以是寫一些注釋描述、流程圖、思維導(dǎo)圖等。

學(xué)習(xí)、工作習(xí)慣

1、遇到不會(huì)的沒有及時(shí)做筆記記錄及學(xué)習(xí)

這位小伙伴剛開始對(duì)一些git常用命令及Linux常用命令不熟悉，我演示過幾遍之后，后面再用到的時(shí)候，讓他自己操作他也還不會(huì)。

我們剛開始參加工作時(shí)，需要一些很常用，但是又不能馬上掌握的知識(shí)點(diǎn)要及時(shí)的記錄寫來、多用，直至掌握。特別是一些流程、步驟之類的，要記錄下來、然后多操作幾次，操作次數(shù)多了，就熟了。

我們做技術(shù)的，還是要有寫文檔、寫總結(jié)的習(xí)慣，這會(huì)加深我們對(duì)某些知識(shí)的理解。寫出來的技術(shù)總結(jié)，如果自己愿意，可以發(fā)到網(wǎng)上，或者自己本地存檔。

2、總想一次性把基礎(chǔ)補(bǔ)好

剛開始時(shí)，這位小伙伴整天閱讀某個(gè)學(xué)習(xí)網(wǎng)站學(xué)習(xí)C語言知識(shí)。以前，我也有這種想法，但是我覺得你只要看懂C語言語法、知道if、else、for等，就可以直接去看項(xiàng)目代碼了，從項(xiàng)目代碼中去學(xué)習(xí)C語言的知識(shí)，項(xiàng)目代碼中，遇到不會(huì)的C語言知識(shí)，針對(duì)性地去查資料進(jìn)行學(xué)習(xí)，這樣印象反而會(huì)更深一些。

其實(shí)看代碼也可以分這么兩種情況：

C語言基礎(chǔ)比較差得情況下，閱讀代碼時(shí)可以先不管這些模塊都實(shí)現(xiàn)了什么功能，就盯著這個(gè)模塊用到的C語言知識(shí)，遇到不會(huì)的C語言知識(shí)就去查資料學(xué)習(xí)。

C語言基礎(chǔ)比較好的情況，就可以看這個(gè)模塊的具體實(shí)現(xiàn)及內(nèi)部機(jī)理。

寫代碼

1、寫代碼之前沒有思考清楚

剛開始時(shí)，這位小伙伴拿到工作任務(wù)時(shí)，還未想清楚就去寫代碼了，導(dǎo)致在開發(fā)的過程中，反復(fù)地進(jìn)行修改。

在接到一個(gè)開發(fā)任務(wù)時(shí)，我們首先要弄清楚需求并大致想清楚整體的實(shí)時(shí)流程，至少要保證大的方向沒錯(cuò)，否則一上來就去編碼，這可能會(huì)做很多無用功。

2、寫代碼不注重編碼規(guī)范

可能是在學(xué)校時(shí)養(yǎng)成了不是很好的編程習(xí)慣，導(dǎo)致他沒有及時(shí)地改過來。我們業(yè)務(wù)自己開發(fā)一些小項(xiàng)目時(shí)，可以有自己遵循的一套編碼規(guī)范。

但是，與他人協(xié)同開發(fā)一個(gè)項(xiàng)目，還是要盡量跟著項(xiàng)目遵循的規(guī)范來進(jìn)行編碼，特別的，在某個(gè)模塊里添加代碼時(shí)，最好參照該模塊的編碼風(fēng)格進(jìn)行編碼，這樣至少可以保證整個(gè)模塊的風(fēng)格是統(tǒng)一的。

3、寫完代碼沒有檢查

以前在學(xué)校，考試的時(shí)候，老師常常強(qiáng)調(diào)答卷做完了要仔細(xì)檢查檢查。同樣的，我們軟件開發(fā)中，平時(shí)寫完代碼，也有必要檢查一下自己寫的代碼，看看有沒有比較明顯的編碼錯(cuò)誤，否則等到調(diào)試階段，出問題可能要找半天。

比如這位小伙伴某次寫case時(shí)忘記寫break了，出問題了，他很懵，還覺得問題很奇怪。

分析問題

1、遇到問題沒有仔細(xì)閱讀問題說明

我們遇到問題時(shí)，要盡可能地去查找原因。特別的，有些問題是有一些比較明顯的問題反饋的，比如編譯錯(cuò)誤、git沖突等。這也是這位小伙伴目前比較欠缺的，遇到問題常常忽略掉問題的提示。

2、遇到問題不會(huì)加一些必要的日志定位問題

平時(shí)，開發(fā)調(diào)試，遇到問題是很正常的事情，有時(shí)候加幾條打印就可以定位到問題的所在，卻一直盯著代碼查半天。特別的，剛接手某個(gè)模塊，對(duì)這個(gè)模塊不是很熟的情況，可以多加一些日志打印，可以很好地幫助我們?nèi)ダ斫庠撃K。

3、容易被問題的表象迷惑

好幾次，遇到問題，他跟我描述問題都是：xxx可以正常運(yùn)行，xxx不行，然后懷疑xxx出了問題。

我們平時(shí)遇到問題，還是要有理有據(jù)地去定位、分析問題，不能瞎猜。更不能害怕問題，我們要清楚，遇到越多地問題，解決越多的問題，我們成長(zhǎng)得越快！

審核編輯 ：李倩