孤單北半球108634571

我從三個層面來說：

• 閱讀業務代碼的方法
  

• 臉皮要厚，不會就問

• 可以考慮換公司

閱讀業務代碼的方法

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

主要流程分四步：

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

臉皮要厚，不會就問

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

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

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

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

可以考慮換公司

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

架構思維

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

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

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

一、端正態度

沒辦法了，我攤牌了！

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

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

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

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

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

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

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

二、從if-else入手

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

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

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

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

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

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

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

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

四、重視積累

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

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

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

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

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

高級Bug調查員

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

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

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

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

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

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

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

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

狂客說技術

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

連cvs都不懂的我

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

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

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

看不懂的就刪

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

刪不掉的就硬著頭皮上

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

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

程序員愛編程

我非計算機專業打的，剛轉行做前端時語法都不太懂，然後剛進公司，老大先給了一本介紹思維導圖的書給我看了一天，後來一週看官方幫助文檔用思維導圖做總結，後來幾個月就開始畫官方api的UML圖，後來畫項目的UML圖。不過很少有公司能這麼有耐心培養你

Roy42757

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

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

大聖湖閒人

穩住，不要慌。

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

為什麼看不懂公司的代碼

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

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

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

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

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

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

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

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

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

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

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

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

會點代碼的大叔

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

1 有師兄

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

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

2 有態度

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

3 有方法

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

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

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

敬請關注

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

IT徐胖子

對於新入職的程序員，如何能快速的熟悉公司業務，並能讀懂公司原有項目的代碼呢？以下三點建議可以參考一下。

1、熟悉公司業務

新入職公司，一般都會有個老人帶你或者公司組織培訓。這是全面瞭解公司業務的好的時機。公司產品屬性，面向群體，盈利模式，都需要了解清楚。

2、親自使用公司的產品

作為新入職的研發人員，對於公司的線上系統或者app一定要實際操作或者下載使用。對於每個功能都要使用一邊。通過使用的過程，自己去設想它背後的實現邏輯。

3、結合系統讀代碼、調試代碼

讀代碼不是拿到一個工程代碼就開始讀。首先，我們搞清它的構建方式。目前很多java工程代碼都是基於maven或者gradle構建，確保本地有相應的環境。其次，嘗試本地啟動工程。在啟動過程中，第一次多半不會成功。不成功的話，一般都會有錯誤信息輸出，我們根據log信息來判斷不能成功啟動的原因。最後，我們開始閱讀代碼。閱讀代碼的時候我們需要結合系統的功能。我們打開系統，分別點擊每一個功能，然後通過瀏覽器的開發者工具或者一些文檔，找到這個功能調用的接口。然後在代碼中找到相應的接口，再具體讀其實現代碼。

總之讀別人的代碼開始都比較痛苦。只要我們找到一個入口，一切就會變得容易。千萬不要拿到代碼，就從第一個代碼文件開始讀。這樣，永遠不會明白其中的邏輯實現。

阿邁達聊技術

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

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

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

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

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

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

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

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

關鍵字: 職場 流程 程序員