1.請教下公司老人公司用什麼框架

2.想辦法讓自己先弄懂公司的框架和用到的技術

3.你接手的專案找你的上級要下相關專案文件研究

4.還沒上手就可以主動請教同事，上級，把你不懂得問題在你實在解決不了的情況下再去問別人，記住千不萬不能第一時間去問別人，先自己找答案試試

5.單獨和領導商量，能否安排一個公司老人帶領你開展工作

加油

我從三個層面來說：

閱讀業務程式碼的方法

臉皮要厚，不會就問

可以考慮換公司

閱讀業務程式碼的方法

之前我回答了一篇關於《如何快速閱讀原始碼》的問題，那個主要是針對閱讀開源框架的，針對公司的業務程式碼，其實流程差不多，我簡單說下不同點。具體流程題主可以去找一下，我就不貼在這裡了。

主要流程分四步：

先「跑起來」：在這裡就是先要去了解專案的業務流程，能夠先搞懂業務是什麼樣的自頂向下拆解：從業務流程對應到程式碼裡面去，先找模組、再到包、然後是類、最後是方法。注意這裡不要在意細節，能夠把類，方法按照業務流程給串起來就行。深入細節：然後再到方法裡面去看具體的細節延伸改進：這是在你梳理完了程式碼之後，再考慮的事情。可以想想為什麼程式碼這麼寫，有沒有什麼更好的方法。臉皮要厚，不會就問

公司肯定有老員工，逮到了就問，別怕人煩，現在你不搞清楚了，後面正式開始寫程式碼的時候，寫出來一堆問題，同事和領導的意見會更大。

我就遇到過幾個人，真的是鬱悶。不問他，一句話都不說，一問全是問題。一些小問題卡了好幾個小時，也不說，就悶在那裡不知道在幹嘛。

按照上面的流程，先找人把業務給理清楚了，然後再去理程式碼。注意程式碼問題也主要關注業務流程層面，而不是語法層面，語法層面的自己去搜搜就可以了。

問的標準是自己十到二十分鐘搞不定的問題，就立刻去問！！！

可以考慮換公司

工作本來就是雙向選擇。如果程式碼邏輯很亂，又沒人能把業務和程式碼給你講清楚，或者沒人願意給你講。那說明這家公司的管理很亂，你可能接的是個鍋，你在這家公司不一定能學到東西，要不要繼續待在這裡是很值得考慮的。

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

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

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

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

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

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

穩住，不要慌。

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

為什麼看不懂公司的程式碼

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

培訓機構的專案，通常業務比較簡單，甚至沒有什麼業務，只是幾個框架做了整合，實現對資料的增刪查改，而公司的專案一定是需要了解業務流程的；

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

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

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

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

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

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

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

利用一切可以利用的文件和註釋；包括需求文件、設計文件、操作手冊、資料庫設計文件等。

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

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

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

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

一、端正態度

沒辦法了，我攤牌了！

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

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

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

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

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

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

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

二、從if-else入手

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

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

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

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

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

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

四、重視積累

這一點要從程式設計經驗來談。

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

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

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

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

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

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

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

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

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

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

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

1 有師兄

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

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

2 有態度

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

3 有方法

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

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

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

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

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

作為一個長期奮鬥在程式開發一線的老程式設計師，也帶過很多新人，對這種接手程式碼後長期沒有讀懂程式碼或者能看懂卻不會獨立維護的情況，遇到過很多。不用著急，可能是你的方法不對，下面說一下我的經驗：

研讀文件

可行性研究報告、需求規格說明書、專案計劃、概要設計說明書、詳細設計說明書這些都是最基本的開發文件，好的文件基本可以將專案的應用背景、實現方式、發展方向都會描述清楚。看這些文件會對將要著手的工作有一個更高層次的認識，而不是僅僅糾結於程式碼本身， 另外，看設計本檔會對程式碼實現的功能上有一個整體的認識，對弄懂程式碼有高屋建瓴的作用。當然很多小公司對文件沒有嚴格要求，或僅僅走個過場，很多開發人員也很煩寫文件，整個專案裡只有一個程式碼在裸奔，文字說明都在程式碼註釋裡，這對後期專案維護造成很大困難。

程式碼模組化拆分

在深入瞭解功能之後，不要著急一行行的去讀程式碼，將程式碼按照功能模組區分出來，知道哪些原始碼檔案是用於實現某個模組功能的，模組與模組之間資料傳遞是怎麼實現的，要傳遞哪些資料，然後一步步將大模組按照功能拆分成小模組，並繼續將程式碼按小模組分類。

依據功能讀懂程式碼

如果能夠將程式碼按照功能模組拆分清楚後，可以試試帶著問題去研究程式碼了，比如為了實現登入功能，畫出流程圖，從頁面的錄入到後臺的判斷再到資料庫的讀寫是怎麼傳遞資料的。

如果只是維護一個專案程式碼功能，哪裡有問題改哪裡，做到這裡基本就夠了，但如果是要對專案進行最佳化升級， 那就必須弄懂原先程式碼為什麼要這樣寫，不要盲目按照自己的理解去修改別人的程式碼，經過實踐的程式碼總有對的理由，牽一髮而動全身，不經過測試使用，不能保證一定沒有bug。

即使你是培訓出來的，如果一個月還熟悉不了公司的產品，那就說明是你的問題，也不要找藉口是公司產品問題如何如何，公司招聘員工就是想讓員工快去熟悉公司產品，快速上手，如果一個月還沒上手，真的可以辭退你了！