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

閱讀代碼

1、閱讀代碼之前沒有先弄清整個項目的框架

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

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

只有了解了這些，我們再去做某個模塊時，能更清楚的知道我們負責的模塊要做什么，才能更好地開發(fā)好這個模塊。

2、閱讀代碼時沒有把握住主線

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

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

我們在閱讀某個模塊的代碼時，盡量沿著這個模塊的主線去閱讀，沿著主線盡可能快地弄清這個模塊做的事情。

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

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

這位小伙伴全面閱讀某個模塊的代碼時，沒有做一些自己的學習、理解記錄，這就會導致看了后面部分，又忘了前面部分。

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

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

學習、工作習慣

1、遇到不會的沒有及時做筆記記錄及學習

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

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

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

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

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

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

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

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

寫代碼

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

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

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

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

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

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

3、寫完代碼沒有檢查

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

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

分析問題

1、遇到問題沒有仔細閱讀問題說明

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

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

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

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

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

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

審核編輯 ：李倩