首先我自己也是培訓班出來的，工作了三年，很有資格說下我的感受。剛出來時，確實有樓主說的情況，看不懂相關公司的代碼，培訓班培訓的跟實際可能存在著差異。代碼本身並不難，大部分有javase知識都能看不懂。難的是公司代碼邏輯的機構和層次。可能他自己封裝了底層，可能他們自己做了框架。可能他們自己重寫了jdk的方法。這很可能是導致新來員工看不懂的原因，其次就是代碼講究獨立性，解偶性，可重複性。可能一個功能的實現，要有大量的架包和方法支持，你從controll看一個方法，他調用了service層，service層做邏輯判斷，可能調用其他包的方法。。。其他包的方法可能又調用了其他包的方法，如此循環下去，導致看不懂。最後就是新技術的引用，現在主流技術是spring微服務，zk,redis,kafka等，可能樓主對這些遠程調用，負載均衡不太熟悉導致看不懂。

對於這三個問題，首先第一個問題。樓主可以多問問老員工，不要害怕他們冷嘲熱諷，只要能賺到錢，這點委屈不算什麼，畢竟公司封裝的自己的東西，真的和所學有所差別。第二個問題，樓主要夯實自己的基礎，知道自己去看代碼，代碼不是一行一行看的，看三層，主要側重看返回值，第三個問題，樓主要樹立終身學習的觀念，程序員不學習，兩三年就會被淘汰，現在技術水平更新那麼快，所以只要有心，這些都不算什麼！

哈哈哈哈，讓我先笑一會。ヾ(^Д^*)/ ，好言歸正傳。

新員工完全看不懂代碼，我推測你可能是剛剛學習編程不久。或者是剛剛從培訓班出來參加工作。

對於你這種情況我非常感同身受。那麼作為一名經歷過你一樣的痛苦的工程師，我會給你一些下面的建議，幫助你從各個方面得到公司同事的認可。

一、端正態度

哈哈哈哈，讓我先笑一會。ヾ(^Д^*)/ ，好言歸正傳。

新員工完全看不懂代碼，我推測你可能是剛剛學習編程不久。或者是剛剛從培訓班出來參加工作。

對於你這種情況我非常感同身受。那麼作為一名經歷過你一樣的痛苦的工程師，我會給你一些下面的建議，幫助你從各個方面得到公司同事的認可。

一、端正態度

沒辦法了，我攤牌了！

神人也不可能讓你立刻看懂公司項目的代碼，熟悉完整流程。那就先從態度上入手。

1、每天一定要早點到公司，身邊準備一個notbook，寫一寫，畫一畫。

2、每天晚上要晚點走，把今天遇到的問題列個清單，做個總結。

3、千萬不要相信“有什麼問題儘管問！”這句鬼話！任何問題，都要先自己去查閱資料，通過自己的努力要解決至少80%的問題。

4、面對上級或者長輩的批評，一定不要掉小臉子！要記住他們，回家再寫在小本本上！

5、做事要積極主動，比如主動請求領導分配給自己一些小的功能做，不要怕做錯，可以在請求任務的時候順便表示一下“有不會的地方一定要多多指點”。

6、適當的誇誇同事的編碼能力，因為這樣可以拉近你和同事之間的距離。

二、從if-else入手

哈哈哈哈，讓我先笑一會。ヾ(^Д^*)/ ，好言歸正傳。

新員工完全看不懂代碼，我推測你可能是剛剛學習編程不久。或者是剛剛從培訓班出來參加工作。

對於你這種情況我非常感同身受。那麼作為一名經歷過你一樣的痛苦的工程師，我會給你一些下面的建議，幫助你從各個方面得到公司同事的認可。

一、端正態度

沒辦法了，我攤牌了！

神人也不可能讓你立刻看懂公司項目的代碼，熟悉完整流程。那就先從態度上入手。

1、每天一定要早點到公司，身邊準備一個notbook，寫一寫，畫一畫。

2、每天晚上要晚點走，把今天遇到的問題列個清單，做個總結。

3、千萬不要相信“有什麼問題儘管問！”這句鬼話！任何問題，都要先自己去查閱資料，通過自己的努力要解決至少80%的問題。

4、面對上級或者長輩的批評，一定不要掉小臉子！要記住他們，回家再寫在小本本上！

5、做事要積極主動，比如主動請求領導分配給自己一些小的功能做，不要怕做錯，可以在請求任務的時候順便表示一下“有不會的地方一定要多多指點”。

6、適當的誇誇同事的編碼能力，因為這樣可以拉近你和同事之間的距離。

二、從if-else入手

說實話，我就是先從最簡單的if-else開始的，把這個記牢。

大部分編程工作就是在不斷的if-else、if-else、if-else.......那句話怎麼說來著？沒錯，人類的本質就是復讀機！

如果你細心一點，你可以發現項目中大多數if-else還是可以看懂的。

三、看代碼的時候假裝自己是一名特工

哈哈哈哈，讓我先笑一會。ヾ(^Д^*)/ ，好言歸正傳。

新員工完全看不懂代碼，我推測你可能是剛剛學習編程不久。或者是剛剛從培訓班出來參加工作。

對於你這種情況我非常感同身受。那麼作為一名經歷過你一樣的痛苦的工程師，我會給你一些下面的建議，幫助你從各個方面得到公司同事的認可。

一、端正態度

沒辦法了，我攤牌了！

神人也不可能讓你立刻看懂公司項目的代碼，熟悉完整流程。那就先從態度上入手。

1、每天一定要早點到公司，身邊準備一個notbook，寫一寫，畫一畫。

2、每天晚上要晚點走，把今天遇到的問題列個清單，做個總結。

3、千萬不要相信“有什麼問題儘管問！”這句鬼話！任何問題，都要先自己去查閱資料，通過自己的努力要解決至少80%的問題。

4、面對上級或者長輩的批評，一定不要掉小臉子！要記住他們，回家再寫在小本本上！

5、做事要積極主動，比如主動請求領導分配給自己一些小的功能做，不要怕做錯，可以在請求任務的時候順便表示一下“有不會的地方一定要多多指點”。

6、適當的誇誇同事的編碼能力，因為這樣可以拉近你和同事之間的距離。

二、從if-else入手

說實話，我就是先從最簡單的if-else開始的，把這個記牢。

大部分編程工作就是在不斷的if-else、if-else、if-else.......那句話怎麼說來著？沒錯，人類的本質就是復讀機！

如果你細心一點，你可以發現項目中大多數if-else還是可以看懂的。

三、看代碼的時候假裝自己是一名特工

這個不可外傳，不過我還是希望能幫助到你。

這個方法就是我在看別人代碼的時候養成的一種小習慣。假設自己是一名正在執行機密任務的中央特工，需要在短時間內破解敵人的內部代碼，維護世界和平！

有了這種心理暗示，你將會不自覺的進入一種戰鬥狀態！腎上腺素暴增！注意力高度集中，效率翻倍！

那麼你的焦慮也會隨之減少，因為沒有時間緊張、恐懼，世界正在等著我去維護正義！

四、重視積累

這一點要從編程經驗來談。

哈哈哈哈，讓我先笑一會。ヾ(^Д^*)/ ，好言歸正傳。

新員工完全看不懂代碼，我推測你可能是剛剛學習編程不久。或者是剛剛從培訓班出來參加工作。

對於你這種情況我非常感同身受。那麼作為一名經歷過你一樣的痛苦的工程師，我會給你一些下面的建議，幫助你從各個方面得到公司同事的認可。

一、端正態度

沒辦法了，我攤牌了！

神人也不可能讓你立刻看懂公司項目的代碼，熟悉完整流程。那就先從態度上入手。

1、每天一定要早點到公司，身邊準備一個notbook，寫一寫，畫一畫。

2、每天晚上要晚點走，把今天遇到的問題列個清單，做個總結。

3、千萬不要相信“有什麼問題儘管問！”這句鬼話！任何問題，都要先自己去查閱資料，通過自己的努力要解決至少80%的問題。

4、面對上級或者長輩的批評，一定不要掉小臉子！要記住他們，回家再寫在小本本上！

5、做事要積極主動，比如主動請求領導分配給自己一些小的功能做，不要怕做錯，可以在請求任務的時候順便表示一下“有不會的地方一定要多多指點”。

6、適當的誇誇同事的編碼能力，因為這樣可以拉近你和同事之間的距離。

二、從if-else入手

說實話，我就是先從最簡單的if-else開始的，把這個記牢。

大部分編程工作就是在不斷的if-else、if-else、if-else.......那句話怎麼說來著？沒錯，人類的本質就是復讀機！

如果你細心一點，你可以發現項目中大多數if-else還是可以看懂的。

三、看代碼的時候假裝自己是一名特工

這個不可外傳，不過我還是希望能幫助到你。

這個方法就是我在看別人代碼的時候養成的一種小習慣。假設自己是一名正在執行機密任務的中央特工，需要在短時間內破解敵人的內部代碼，維護世界和平！

有了這種心理暗示，你將會不自覺的進入一種戰鬥狀態！腎上腺素暴增！注意力高度集中，效率翻倍！

那麼你的焦慮也會隨之減少，因為沒有時間緊張、恐懼，世界正在等著我去維護正義！

四、重視積累

這一點要從編程經驗來談。

對於軟件行業來說，編程經驗都是需要不斷積累的，而且每個人都是這樣走過來的，不用害怕。

你不必一天吃成一個胖子，只需要每天提高自己，將昨天的學習不斷總結，你就會看到驚人的變化。

正所謂“不積跬步無以至千里”，其實你的領導和同事也沒有要求你是個天才，你只需要像一個正常人一樣，犯過的錯誤，不要重複犯錯，掌握的知識能夠樂於分享就可以了。他們一定會看到你的成長，並給予你鼓勵，這個世界還是挺寬容的。

綜上，就是我提供的幫助，希望點贊、關注哦！

這個問題讓我想起了剛畢業參加工作那會兒，進公司頭幾天也是一年懵逼的狀態。在這裡就分享一下我是如何從學生模式調整成員工模式的吧。

這個問題讓我想起了剛畢業參加工作那會兒，進公司頭幾天也是一年懵逼的狀態。在這裡就分享一下我是如何從學生模式調整成員工模式的吧。

連cvs都不懂的我

十多年前參加工作的時候，公司還在使用cvs來作版本控制。進公司第一天就要求把代碼下載下來研究，負責帶我們的老同事就問了一句：cvs會嗎？為了不丟面兒，我和一個一起進公司的同學異口同聲的回答：會！畢竟畢業實習的時候好像用過。

一上午就這樣過去了，一個代碼影子都沒看到。最後還是虛心的請教了前輩，才拿到了代碼。

這個問題讓我想起了剛畢業參加工作那會兒，進公司頭幾天也是一年懵逼的狀態。在這裡就分享一下我是如何從學生模式調整成員工模式的吧。

連cvs都不懂的我

十多年前參加工作的時候，公司還在使用cvs來作版本控制。進公司第一天就要求把代碼下載下來研究，負責帶我們的老同事就問了一句：cvs會嗎？為了不丟面兒，我和一個一起進公司的同學異口同聲的回答：會！畢竟畢業實習的時候好像用過。

一上午就這樣過去了，一個代碼影子都沒看到。最後還是虛心的請教了前輩，才拿到了代碼。

說實話，我們當時看到的代碼就是你說的control、service、dao，標準的MVC框架！可是我們在學校沒見過呀，我只知道java可以寫application，最多知道可以寫servlet，MVC什麼的聽都沒聽過。

看不懂的就刪

我最開始接觸的這個項目也有4、5年的開發歷史了，裡面的千瘡百孔只有經歷過的人才知道。看著代碼裡面一段段讓人心酸的註釋，讓我下定了決心要刪掉它們。就這樣，一段段的歷史，被我成功改寫。

刪不掉的就硬著頭皮上

這個問題讓我想起了剛畢業參加工作那會兒，進公司頭幾天也是一年懵逼的狀態。在這裡就分享一下我是如何從學生模式調整成員工模式的吧。

連cvs都不懂的我

十多年前參加工作的時候，公司還在使用cvs來作版本控制。進公司第一天就要求把代碼下載下來研究，負責帶我們的老同事就問了一句：cvs會嗎？為了不丟面兒，我和一個一起進公司的同學異口同聲的回答：會！畢竟畢業實習的時候好像用過。

一上午就這樣過去了，一個代碼影子都沒看到。最後還是虛心的請教了前輩，才拿到了代碼。

說實話，我們當時看到的代碼就是你說的control、service、dao，標準的MVC框架！可是我們在學校沒見過呀，我只知道java可以寫application，最多知道可以寫servlet，MVC什麼的聽都沒聽過。

看不懂的就刪

我最開始接觸的這個項目也有4、5年的開發歷史了，裡面的千瘡百孔只有經歷過的人才知道。看著代碼裡面一段段讓人心酸的註釋，讓我下定了決心要刪掉它們。就這樣，一段段的歷史，被我成功改寫。

刪不掉的就硬著頭皮上

實際上，能夠被我們這些新手重寫的代碼並不多，大量的代碼是看上去就像天書一樣看不懂邏輯，也沒有註釋，而且還很長。我相信前輩也不願意寫的這麼複雜，只是因為複雜的業務邏輯導致了這誇張的代碼。所以就要趕緊了解業務邏輯，當你十分了解這段代碼的業務邏輯之後，也就基本上明白了這段長代碼的意義了。

所以我覺得剛入職一個月還沒入門沒有關係，每個公司的框架都可能有不同的風格，一定要虛心請教老同事，大膽嘗試自己的想法，努力學習和了解公司的業務，這樣你才能快速的成長起來。

我是程序員愛編程，一個資深非專業碼農，科技領域段子手！如本回答能夠討得您的歡心，勞請點贊、轉發、關注我，如有不同看法可以在評論區留言，謝謝！

兄弟，堅持住！感覺你還沒有入門兒，但是也不用或許焦慮，編程這就是這樣，剛開始特別難熬，熬著熬著越來越輕鬆，畢竟編程門坎還是有一些的。

說說我的經歷吧可能比較久遠了，12年大學畢業來北京工作，學的計算機科學與技術，當然除了helle world程序別的真的就很費勁兒，基本分為以下幾個階段。

兄弟，堅持住！感覺你還沒有入門兒，但是也不用或許焦慮，編程這就是這樣，剛開始特別難熬，熬著熬著越來越輕鬆，畢竟編程門坎還是有一些的。

說說我的經歷吧可能比較久遠了，12年大學畢業來北京工作，學的計算機科學與技術，當然除了helle world程序別的真的就很費勁兒，基本分為以下幾個階段。

1，初窺門徑(小白價格，學會為目標，初級開發工程師)

2，登堂入室(完成任務為目標，初中級開發)

3，得心應手(輕鬆完成任務，工作逐漸由腦力勞動轉為體力)

4，融匯貫通(高開，逐漸擺脫純體力工作，思考架構問題)

而且我是從來沒接觸過的delphi，java大學還學了一點，delphi就是個全新的東西了，那段時間差不多一個半月吧真的挺難熬，天天加班到十點以後，其實當時壓力大，看到別人都會而自己跟不上特別急躁，越急躁大腦越不清晰，加班也沒啥效率，根本就是磨時間，無奈拋開任務看書，看基礎知識，就這樣堅持認真看了大半本delphi指導書才有初窺門徑的感覺，開始覺得一天比一天輕鬆了，慢慢能夠理解之前的一些東西了，遇到簡單問題也不會手足無措了。感覺兄弟還沒過這個階段。可能公司的架構和培訓的有出入，畢竟培訓是入門級別的應用，每個公司根據自身業務會調整代碼結構，做高聚合的分層，這樣對入門級別的小白來說難度就大了很多，但是別灰心，堅持學習相關知識，投入更多的時間去看公司代碼，從一個外部請求開始，還原代碼鏈路，在這個過程中梳理公司技術架構，多做筆記多請教，有兩週時間你的信心就回來了！

兄弟，堅持住！感覺你還沒有入門兒，但是也不用或許焦慮，編程這就是這樣，剛開始特別難熬，熬著熬著越來越輕鬆，畢竟編程門坎還是有一些的。

說說我的經歷吧可能比較久遠了，12年大學畢業來北京工作，學的計算機科學與技術，當然除了helle world程序別的真的就很費勁兒，基本分為以下幾個階段。

1，初窺門徑(小白價格，學會為目標，初級開發工程師)

2，登堂入室(完成任務為目標，初中級開發)

3，得心應手(輕鬆完成任務，工作逐漸由腦力勞動轉為體力)

4，融匯貫通(高開，逐漸擺脫純體力工作，思考架構問題)

而且我是從來沒接觸過的delphi，java大學還學了一點，delphi就是個全新的東西了，那段時間差不多一個半月吧真的挺難熬，天天加班到十點以後，其實當時壓力大，看到別人都會而自己跟不上特別急躁，越急躁大腦越不清晰，加班也沒啥效率，根本就是磨時間，無奈拋開任務看書，看基礎知識，就這樣堅持認真看了大半本delphi指導書才有初窺門徑的感覺，開始覺得一天比一天輕鬆了，慢慢能夠理解之前的一些東西了，遇到簡單問題也不會手足無措了。感覺兄弟還沒過這個階段。可能公司的架構和培訓的有出入，畢竟培訓是入門級別的應用，每個公司根據自身業務會調整代碼結構，做高聚合的分層，這樣對入門級別的小白來說難度就大了很多，但是別灰心，堅持學習相關知識，投入更多的時間去看公司代碼，從一個外部請求開始，還原代碼鏈路，在這個過程中梳理公司技術架構，多做筆記多請教，有兩週時間你的信心就回來了！

大狂客，七年軟件開發，三年架構！持續為大家解惑，歡迎關注！

穩住，不要慌。

剛參加工作的Java程序員，看不懂公司的代碼是很正常的一件事兒，不過題主已經入職一個月了，如果依然是懵懵懂懂的狀態，那麼一定要緊張起來了。

為什麼看不懂公司的代碼

• 題主說自己是培訓機構出身，通常來說，培訓機構為了把一個學員短期內培訓出來，通常培訓的內容都是停留在“會用”這個程度。大部分時候會告訴學員，這樣做可以，那樣寫可以；但是如果稍加變化的話，有時候學員就變得無從下手的；
  

• 培訓機構的項目，通常業務比較簡單，甚至沒有什麼業務，只是幾個框架做了集成，實現對數據的增刪查改，而公司的項目一定是需要了解業務流程的；
  

• 題主說自己瞭解Control,Service,Dao這些代碼分層，因為這是培訓機構教科書似的項目，而且確實應該這樣遵守；不過現實中，特別是老項目，有些公司是不注意這些代碼規範和分層的，或者雖然有分層，但是程序員沒有嚴格要求，比如Service層直接訪問了數據庫，Dao中包含了複雜的業務邏輯；所以你會覺得“雜七雜八的一大堆”。
  

穩住，不要慌。

剛參加工作的Java程序員，看不懂公司的代碼是很正常的一件事兒，不過題主已經入職一個月了，如果依然是懵懵懂懂的狀態，那麼一定要緊張起來了。

為什麼看不懂公司的代碼

• 題主說自己是培訓機構出身，通常來說，培訓機構為了把一個學員短期內培訓出來，通常培訓的內容都是停留在“會用”這個程度。大部分時候會告訴學員，這樣做可以，那樣寫可以；但是如果稍加變化的話，有時候學員就變得無從下手的；
  

• 培訓機構的項目，通常業務比較簡單，甚至沒有什麼業務，只是幾個框架做了集成，實現對數據的增刪查改，而公司的項目一定是需要了解業務流程的；
  

• 題主說自己瞭解Control,Service,Dao這些代碼分層，因為這是培訓機構教科書似的項目，而且確實應該這樣遵守；不過現實中，特別是老項目，有些公司是不注意這些代碼規範和分層的，或者雖然有分層，但是程序員沒有嚴格要求，比如Service層直接訪問了數據庫，Dao中包含了複雜的業務邏輯；所以你會覺得“雜七雜八的一大堆”。
  

那麼需要如何解決呢？給題主幾條建議：

• 首先，最容易改變的就是工作態度，既然工作比較吃力，那麼多投入一些時間，沒事兒多加加班，至少讓領導覺得你是一個肯吃苦的新人；

• 不懂就多問：通常新人進公司，都會安排一個老人帶的，如果沒有特殊指定的話，你可以選擇問直屬的領導，或者項目組中看起來比較和藹的前輩，都可以直接問；

• 詢問之前，你至少看過代碼，帶著問題去問，千萬別上來就說：“代碼我看不懂，你給我講講”；

• 自己看代碼的時候，首先要在自己電腦上，把項目跑起來，知道功能入口是什麼；比如有些系統有前端頁面，那麼功能入口就是前臺頁面的某個操作；有些系統沒有頁面，那麼入口可能是接口或定時服務；一定要了解如何操作，然後給代碼加上斷點，一步一步地跟蹤下來，瞭解一個功能是如何觸發、處理、返回；

• 每次問問題之後，如果當時不能理解，一定要先記錄下來，然後再反覆地看代碼；簡單的問題，千萬不要重複問；

• 利用一切可以利用的文檔和註釋；包括需求文檔、設計文檔、操作手冊、數據庫設計文檔等。

剛工作的這段階段是很痛苦的，一定要多投入些時間，早日突破這個瓶頸期。

穩住，不要慌。

剛參加工作的Java程序員，看不懂公司的代碼是很正常的一件事兒，不過題主已經入職一個月了，如果依然是懵懵懂懂的狀態，那麼一定要緊張起來了。

為什麼看不懂公司的代碼

• 題主說自己是培訓機構出身，通常來說，培訓機構為了把一個學員短期內培訓出來，通常培訓的內容都是停留在“會用”這個程度。大部分時候會告訴學員，這樣做可以，那樣寫可以；但是如果稍加變化的話，有時候學員就變得無從下手的；
  

• 培訓機構的項目，通常業務比較簡單，甚至沒有什麼業務，只是幾個框架做了集成，實現對數據的增刪查改，而公司的項目一定是需要了解業務流程的；
  

• 題主說自己瞭解Control,Service,Dao這些代碼分層，因為這是培訓機構教科書似的項目，而且確實應該這樣遵守；不過現實中，特別是老項目，有些公司是不注意這些代碼規範和分層的，或者雖然有分層，但是程序員沒有嚴格要求，比如Service層直接訪問了數據庫，Dao中包含了複雜的業務邏輯；所以你會覺得“雜七雜八的一大堆”。
  

那麼需要如何解決呢？給題主幾條建議：

• 首先，最容易改變的就是工作態度，既然工作比較吃力，那麼多投入一些時間，沒事兒多加加班，至少讓領導覺得你是一個肯吃苦的新人；

• 不懂就多問：通常新人進公司，都會安排一個老人帶的，如果沒有特殊指定的話，你可以選擇問直屬的領導，或者項目組中看起來比較和藹的前輩，都可以直接問；

• 詢問之前，你至少看過代碼，帶著問題去問，千萬別上來就說：“代碼我看不懂，你給我講講”；

• 自己看代碼的時候，首先要在自己電腦上，把項目跑起來，知道功能入口是什麼；比如有些系統有前端頁面，那麼功能入口就是前臺頁面的某個操作；有些系統沒有頁面，那麼入口可能是接口或定時服務；一定要了解如何操作，然後給代碼加上斷點，一步一步地跟蹤下來，瞭解一個功能是如何觸發、處理、返回；

• 每次問問題之後，如果當時不能理解，一定要先記錄下來，然後再反覆地看代碼；簡單的問題，千萬不要重複問；

• 利用一切可以利用的文檔和註釋；包括需求文檔、設計文檔、操作手冊、數據庫設計文檔等。

剛工作的這段階段是很痛苦的，一定要多投入些時間，早日突破這個瓶頸期。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

穩住，不要慌。

剛參加工作的Java程序員，看不懂公司的代碼是很正常的一件事兒，不過題主已經入職一個月了，如果依然是懵懵懂懂的狀態，那麼一定要緊張起來了。

為什麼看不懂公司的代碼

• 題主說自己是培訓機構出身，通常來說，培訓機構為了把一個學員短期內培訓出來，通常培訓的內容都是停留在“會用”這個程度。大部分時候會告訴學員，這樣做可以，那樣寫可以；但是如果稍加變化的話，有時候學員就變得無從下手的；
  

• 培訓機構的項目，通常業務比較簡單，甚至沒有什麼業務，只是幾個框架做了集成，實現對數據的增刪查改，而公司的項目一定是需要了解業務流程的；
  

• 題主說自己瞭解Control,Service,Dao這些代碼分層，因為這是培訓機構教科書似的項目，而且確實應該這樣遵守；不過現實中，特別是老項目，有些公司是不注意這些代碼規範和分層的，或者雖然有分層，但是程序員沒有嚴格要求，比如Service層直接訪問了數據庫，Dao中包含了複雜的業務邏輯；所以你會覺得“雜七雜八的一大堆”。
  

那麼需要如何解決呢？給題主幾條建議：

• 首先，最容易改變的就是工作態度，既然工作比較吃力，那麼多投入一些時間，沒事兒多加加班，至少讓領導覺得你是一個肯吃苦的新人；

• 不懂就多問：通常新人進公司，都會安排一個老人帶的，如果沒有特殊指定的話，你可以選擇問直屬的領導，或者項目組中看起來比較和藹的前輩，都可以直接問；

• 詢問之前，你至少看過代碼，帶著問題去問，千萬別上來就說：“代碼我看不懂，你給我講講”；

• 自己看代碼的時候，首先要在自己電腦上，把項目跑起來，知道功能入口是什麼；比如有些系統有前端頁面，那麼功能入口就是前臺頁面的某個操作；有些系統沒有頁面，那麼入口可能是接口或定時服務；一定要了解如何操作，然後給代碼加上斷點，一步一步地跟蹤下來，瞭解一個功能是如何觸發、處理、返回；

• 每次問問題之後，如果當時不能理解，一定要先記錄下來，然後再反覆地看代碼；簡單的問題，千萬不要重複問；

• 利用一切可以利用的文檔和註釋；包括需求文檔、設計文檔、操作手冊、數據庫設計文檔等。

剛工作的這段階段是很痛苦的，一定要多投入些時間，早日突破這個瓶頸期。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

程序員都是從新人過來的，不要著急，我認為可以從三個方面來解決：

1 有師兄

大公司一般都有師兄制。所謂師兄制就是項目組會為新同事分配一個固定的師兄，帶著熟悉業務和相關技術框架。師弟對代碼掌握情況和能否快速融入團隊是師兄考核指標。我認為這是非常好的傳幫帶模式。

如果沒有師兄制，建議你主動為找一個師兄，虛心向他請教和學習，師兄可以幫你少走技術彎路。

2 有態度

師兄平常也有自己繁忙的工作，所以關鍵還是要靠自己。師兄可以幫你少走彎路，但是大量的學習工作還是要靠自己，所以剛進項目組要比別人多花時間鑽研，看代碼，看文檔，看架構圖。

3 有方法

首先從項目全貌來觀察項目，最好有業務架構圖和技術架構圖。業務架構圖幫你梳理整個業務解決了什麼問題，進入了什麼階段。技術架構圖拆解了每個技術模塊，要熟悉每個技術模塊作用，以及自己要做的模塊處在整個技術架構的什麼位置。

其次要讀代碼。從功能最核心的入口開始，把項目跑起來，斷點把代碼跟進下去，我認為這是比較有效的方法。

最後要動手練。光看是不夠的，要從一個簡單的功能開始做起來，邊做邊熟悉，並且要跟進整個項目週期（需求、設計、開發、測試、打包、上線、監控）為後續複雜功能做準備。

敬請關注

請點擊關注按鈕【IT徐胖子】會持續為大家奉獻互聯網和技術乾貨內容，感謝支持

謝謝邀請！

不少新入職的程序員往往都會遇到類似的問題，但是有過實習經歷的程序員遇到類似的問題會從容很多，畢竟瞭解了軟件開發的流程和環節會對閱讀代碼有較大的幫助。

謝謝邀請！

不少新入職的程序員往往都會遇到類似的問題，但是有過實習經歷的程序員遇到類似的問題會從容很多，畢竟瞭解了軟件開發的流程和環節會對閱讀代碼有較大的幫助。

通常情況下，要想能夠快速瞭解代碼並融入到開發團隊中，應該做好以下幾件事：

第一：從功能入手。不少公司的代碼都是經過多個程序員的編寫，難免在書寫的過程中存在一些不規範的情況，要想了解這些代碼最直接的方式就是從功能入手，根據功能的執行過程來梳理代碼結構。不少程序員在半路接手別人代碼的時候，通常都是採用類似的方案，這樣也不會影響新功能的開發。

第二：做好標註。有的程序員在看代碼的過程中會對代碼進行一定的標註，標註的過程一方面可以梳理代碼的功能，另一方面也方便回頭再看。不少初級程序員採用標註代碼的方式是比較適合的，因為標註代碼的過程也是學習的過程。

第三：注重交流。不同團隊往往都有較為統一的編碼規則，所以對於初入團隊的新人來說，應該多找機會與團隊中的主力程序員進行交流，在交流的過程中往往就能瞭解到一些編碼的結構和規則，這對於閱讀代碼是有較大幫助的。另外，遇到比較棘手的問題時，也不要一味的自己思考，完全可以通過交流得到答案。作為新人來說，一定不要不好意思，因為這也是為了工作能夠順利開展。目前不少科技公司也會為新人配備一名主力程序員，這樣會提升新人的成長速度。

對於初入職場的程序員來說，一方面要多讀代碼，另一方面也要多動手敲代碼，隨著自身編程能力的提升，閱讀代碼的能力也會隨之提高。

我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。

如果有互聯網方面的問題，也可以諮詢我，謝謝！

我是一個java程序員，我願意分享我的見解僅供參考，如果有不同意見和想法，歡迎留言交流，更歡迎關注後私信探討。

這個情況分開來看，如果你是一位職場新人，這種情況還可以理解，不必慌張。但如果你是一個剛換工作的有經驗的老人，這就要好好思考下問題所在了。但無論如何，我都建議出現這種情況不要亂了陣腳，過於懷疑自己的能力，要冷靜分析問題，找到解決方案。

我是一個java程序員，我願意分享我的見解僅供參考，如果有不同意見和想法，歡迎留言交流，更歡迎關注後私信探討。

這個情況分開來看，如果你是一位職場新人，這種情況還可以理解，不必慌張。但如果你是一個剛換工作的有經驗的老人，這就要好好思考下問題所在了。但無論如何，我都建議出現這種情況不要亂了陣腳，過於懷疑自己的能力，要冷靜分析問題，找到解決方案。

學習和工作是兩碼事兒，要做好充分的心理準備

我認為學習是基本知識點積累的過程，主要是解決從0到1的問題，即掌握工作的技能。而工作則是要把所學的技術和能力充分的綜合運用。一個是輸入的過程，一個是輸出的過程。而且工作並不是簡單的技能輸出，而是需要自己去理解、整合、選取的綜合性應用。所以由學習到工作的轉變，我們要做好充分的思想準備，這樣才能未雨綢繆，迎難而上。

我是一個java程序員，我願意分享我的見解僅供參考，如果有不同意見和想法，歡迎留言交流，更歡迎關注後私信探討。

這個情況分開來看，如果你是一位職場新人，這種情況還可以理解，不必慌張。但如果你是一個剛換工作的有經驗的老人，這就要好好思考下問題所在了。但無論如何，我都建議出現這種情況不要亂了陣腳，過於懷疑自己的能力，要冷靜分析問題，找到解決方案。

學習和工作是兩碼事兒，要做好充分的心理準備

我認為學習是基本知識點積累的過程，主要是解決從0到1的問題，即掌握工作的技能。而工作則是要把所學的技術和能力充分的綜合運用。一個是輸入的過程，一個是輸出的過程。而且工作並不是簡單的技能輸出，而是需要自己去理解、整合、選取的綜合性應用。所以由學習到工作的轉變，我們要做好充分的思想準備，這樣才能未雨綢繆，迎難而上。

學習是持續的過程，不要期望一勞永逸

我們即使掌握了所學的所有內容，也不要單純的認為，自己就可以在職業的道路上一馬平川。況且我們所學的知識有限，無論是通過刻苦自學，還是在培訓機構培訓學習，學到的應該是一種能力。據我的瞭解我們的學校知識點跟不上企業需求，而培訓機構又缺乏項目實戰。我曾在培訓機構有過兼職講師，實話講即使有所謂的項目實戰，跟企業中真正的項目相比，還是小巫見大巫了。所以我們要保持永遠學習的思想準備，尤其是IT領域知識的更新速度快，更加需要我們不斷更新自己的知識庫。

我是一個java程序員，我願意分享我的見解僅供參考，如果有不同意見和想法，歡迎留言交流，更歡迎關注後私信探討。

這個情況分開來看，如果你是一位職場新人，這種情況還可以理解，不必慌張。但如果你是一個剛換工作的有經驗的老人，這就要好好思考下問題所在了。但無論如何，我都建議出現這種情況不要亂了陣腳，過於懷疑自己的能力，要冷靜分析問題，找到解決方案。

學習和工作是兩碼事兒，要做好充分的心理準備

我認為學習是基本知識點積累的過程，主要是解決從0到1的問題，即掌握工作的技能。而工作則是要把所學的技術和能力充分的綜合運用。一個是輸入的過程，一個是輸出的過程。而且工作並不是簡單的技能輸出，而是需要自己去理解、整合、選取的綜合性應用。所以由學習到工作的轉變，我們要做好充分的思想準備，這樣才能未雨綢繆，迎難而上。

學習是持續的過程，不要期望一勞永逸

我們即使掌握了所學的所有內容，也不要單純的認為，自己就可以在職業的道路上一馬平川。況且我們所學的知識有限，無論是通過刻苦自學，還是在培訓機構培訓學習，學到的應該是一種能力。據我的瞭解我們的學校知識點跟不上企業需求，而培訓機構又缺乏項目實戰。我曾在培訓機構有過兼職講師，實話講即使有所謂的項目實戰，跟企業中真正的項目相比，還是小巫見大巫了。所以我們要保持永遠學習的思想準備，尤其是IT領域知識的更新速度快，更加需要我們不斷更新自己的知識庫。

技術重要，業務更加重要

針對這個問題，我想強調的是技術重要，但業務更加重要。看不懂代碼不要緊，我當初剛畢業工作時也存在這種情況。如果你是培訓出來的，看到這些看不懂的代碼更不要驚訝。我在工作中發現，一個企業、公司尤其是系統很多的單位，他們是由來自不同廠家、或者團隊開發的，採用的技術體系和技術架構都不一樣。就跟你在機構學習的MVC三層架構和現在看到的代碼不同的情況一樣。要知道不是所有的java系統都是MVC架構。

理解了這一點，後面就好辦了，所以你不要慌，不要認為自己學習了個假java，也不要認為公司故意為難你，讓你接手爛項目。我的經驗來講，無論技術架構如何，最終服務的是業務，所以你要從業務的角度出發，來理解系統的整體設計和功能模塊，站在全局的角度來看問題，慢慢切入到具體得代碼實現，這樣一個循序漸進的過程，一定沒有問題。

我是一個java程序員，我願意分享我的見解僅供參考，如果有不同意見和想法，歡迎留言交流，更歡迎關注後私信探討。

這個情況分開來看，如果你是一位職場新人，這種情況還可以理解，不必慌張。但如果你是一個剛換工作的有經驗的老人，這就要好好思考下問題所在了。但無論如何，我都建議出現這種情況不要亂了陣腳，過於懷疑自己的能力，要冷靜分析問題，找到解決方案。

學習和工作是兩碼事兒，要做好充分的心理準備

我認為學習是基本知識點積累的過程，主要是解決從0到1的問題，即掌握工作的技能。而工作則是要把所學的技術和能力充分的綜合運用。一個是輸入的過程，一個是輸出的過程。而且工作並不是簡單的技能輸出，而是需要自己去理解、整合、選取的綜合性應用。所以由學習到工作的轉變，我們要做好充分的思想準備，這樣才能未雨綢繆，迎難而上。

學習是持續的過程，不要期望一勞永逸

我們即使掌握了所學的所有內容，也不要單純的認為，自己就可以在職業的道路上一馬平川。況且我們所學的知識有限，無論是通過刻苦自學，還是在培訓機構培訓學習，學到的應該是一種能力。據我的瞭解我們的學校知識點跟不上企業需求，而培訓機構又缺乏項目實戰。我曾在培訓機構有過兼職講師，實話講即使有所謂的項目實戰，跟企業中真正的項目相比，還是小巫見大巫了。所以我們要保持永遠學習的思想準備，尤其是IT領域知識的更新速度快，更加需要我們不斷更新自己的知識庫。

技術重要，業務更加重要

針對這個問題，我想強調的是技術重要，但業務更加重要。看不懂代碼不要緊，我當初剛畢業工作時也存在這種情況。如果你是培訓出來的，看到這些看不懂的代碼更不要驚訝。我在工作中發現，一個企業、公司尤其是系統很多的單位，他們是由來自不同廠家、或者團隊開發的，採用的技術體系和技術架構都不一樣。就跟你在機構學習的MVC三層架構和現在看到的代碼不同的情況一樣。要知道不是所有的java系統都是MVC架構。

理解了這一點，後面就好辦了，所以你不要慌，不要認為自己學習了個假java，也不要認為公司故意為難你，讓你接手爛項目。我的經驗來講，無論技術架構如何，最終服務的是業務，所以你要從業務的角度出發，來理解系統的整體設計和功能模塊，站在全局的角度來看問題，慢慢切入到具體得代碼實現，這樣一個循序漸進的過程，一定沒有問題。

多和團隊成員溝通，多看資料文檔

任何項目或系統都有其相關技術文檔，可以先掌握文檔資料像需求說明書、架構設計說明書、系統實現說明書等資料。我強烈建議你要多和團隊內成員溝通交流，有老司機帶路，你才能更快的進步！記住，java基礎知識一定要牢固，不要讓基本知識點成為攔路虎！

感覺雜七雜八的一大堆，完全不知道從何入手，也不知道代碼邏輯，有以下3個可能的原因：

1.公司的代碼用了你完全沒接觸過的框架，不知道框架的原理。

2.公司的項目代碼用了一些複雜的設計模式，你以前在培訓班沒接觸過，看不出個頭緒來。

3.公司的代碼管理不完善，為了完成業務邏輯堆砌代碼，代碼沒有進行合理的模塊化和分層。由於歷史遺留問題太多，代碼只能湊合著用。

1,2 兩種情況相對還好解決，最怕的就是3的情況。

感覺雜七雜八的一大堆，完全不知道從何入手，也不知道代碼邏輯，有以下3個可能的原因：

1.公司的代碼用了你完全沒接觸過的框架，不知道框架的原理。

2.公司的項目代碼用了一些複雜的設計模式，你以前在培訓班沒接觸過，看不出個頭緒來。

3.公司的代碼管理不完善，為了完成業務邏輯堆砌代碼，代碼沒有進行合理的模塊化和分層。由於歷史遺留問題太多，代碼只能湊合著用。

1,2 兩種情況相對還好解決，最怕的就是3的情況。

第3種情況就是傳說中的祖傳bug，碰到其中一塊，就會產生各種奇奇怪怪的問題，而且找不出原因。

不過沒關係，穩住不要慌，這3種情況我都遇到過，畢竟是曾經換了3次工作的老程序員了。

現在，你最急需做的第一件事就是，搞清楚，目前的情況是屬於上述三種情況中的哪一種，或者更糟，混合了其中的幾種？

謙虛一點哈，找小組長或者是老同事問一下，現在的項目中，用到了哪些框架，用到了哪些設計模式，請他給你講一講(千萬不要說代碼寫得雜七雜八，看不懂代碼邏輯，說不定就是眼前這個人寫的代碼)。最好拿個小本本記下來，要問的問題除了這兩個，還請他們幫你指出來框架和設計模式體現在代碼裡面哪一部分。

感覺雜七雜八的一大堆，完全不知道從何入手，也不知道代碼邏輯，有以下3個可能的原因：

1.公司的代碼用了你完全沒接觸過的框架，不知道框架的原理。

2.公司的項目代碼用了一些複雜的設計模式，你以前在培訓班沒接觸過，看不出個頭緒來。

3.公司的代碼管理不完善，為了完成業務邏輯堆砌代碼，代碼沒有進行合理的模塊化和分層。由於歷史遺留問題太多，代碼只能湊合著用。

1,2 兩種情況相對還好解決，最怕的就是3的情況。

第3種情況就是傳說中的祖傳bug，碰到其中一塊，就會產生各種奇奇怪怪的問題，而且找不出原因。

不過沒關係，穩住不要慌，這3種情況我都遇到過，畢竟是曾經換了3次工作的老程序員了。

現在，你最急需做的第一件事就是，搞清楚，目前的情況是屬於上述三種情況中的哪一種，或者更糟，混合了其中的幾種？

謙虛一點哈，找小組長或者是老同事問一下，現在的項目中，用到了哪些框架，用到了哪些設計模式，請他給你講一講(千萬不要說代碼寫得雜七雜八，看不懂代碼邏輯，說不定就是眼前這個人寫的代碼)。最好拿個小本本記下來，要問的問題除了這兩個，還請他們幫你指出來框架和設計模式體現在代碼裡面哪一部分。

態度一定要好，一定要誠懇，大家都是從這個階段過來的，一般都願意幫忙。嘴巴可以甜一點，可以送可樂送小零食，幫忙打水，幫忙買早飯，甚至是請吃飯，不要不好意思，這些事情我都做過。

同事幫你指出來的，你一定要認真聽，仔細去去消化。哪怕早上早一點來，晚上晚一點走，一定要搞清楚。自己理解了之後，可以畫畫圖，總結一下，請同事幫你看看理解的對不對。

新入職的程序員，一般都是剛畢業或者是實習生，不懂代碼沒關係，既然面試通過了，就有留下你的道理。代碼不懂沒關係，先問問自己應該做哪一塊的業務。然後去看那個地方的代碼，不懂就上網搜，網上沒有什麼是你搜不到的。然後主動的去找你的經理要一些小活兒幹，不要灰心，其實你可以的，幹活的過程中肯定會遇到很多問題，就虛心的去問就好了，沒有人笑話你的，大家都是這樣過來的。

但是一定要讓大家看到你的進步和努力。

記住以下三點：

一：勤學好問，知錯就改

二：紮好基礎知識，不斷給自己充電

三：多看公司代碼，縷清楚業務