Struggle1
我是11年7月入行的，那會剛畢業然後半年培訓出來的，剛踏入社會很渴望立馬就工作進去職場，只要有公司收留我我就很開心所以第一家公司待了有7年時間。入職沒多久就跟著一個比我早的同事學習跟著做，公司人都很好我也比較好學所以沒多久就熟悉了公司的框架和業務。一開始會分派一些維護工作帶著熟悉系統，後來漸漸熟練了就直接負責一個模塊到後來就是項目負責和系統設計。程序員這一行必須有些濃烈的興趣進入職場，目前快10年還有3年左右本人就不想幹了，有點無聊不刺激，哈哈哈(ಡωಡ)hiahiahia
LancCJ
我從 07 年的時候進入職場，成為了一名程序員，到現在已經十多年了，在最初進入職場的時候，我也和題主一樣茫然過、無所適從過；我從一個剛畢業的學生轉變成公司的一名員工，“入門”就大概花了兩三個月的時間，如果算真正地適應職場的節奏，大概用了半年的時間。
01. 初入職場的困境
我在工作之前，掌握著 Java 的基本語法，以及那時候非常流程的 SSH 框架，當然只停留在“使用”這個程度，而我的第一個項目，拿到的源碼是基於 Buffalo 寫的，可能大部分同學看到這裡會一臉蒙，這是個什麼框架？我怎麼都沒聽說過？這是一個國產的 AJAX 框架，具體大家可以不用瞭解，我只簡要的概括一下這個框架：你只需要寫也頁面中的 JavaScript 就可以完成對數據庫的增刪查改，所有的業務邏輯也都在 JS 中的。
是的，在工作的第一個半年，我沒有摸過 Java，一直都在寫 JS！其實這並不是重點，那個階段對於我最困難的是：以我當時的技術積累，在面對一個全新的技術框架的時候，學起來是非常困難的，甚至會無從下手。
02. 對於這個階段的建議
能力不夠，態度來湊：雖然我個人是不建議加班的，但是在這個“未入門”的階段，建議還是加加班，多看看項目的代碼，爭取早日上手；另外也可以讓領導看到你的工作態度。
不懂就問，但是一定要經過思考：新人難免有很多不懂的地方，所以你可以去問你的同事和領導，但是不要遇到問題就去問，而是先經過自己的思考，自己想了一些辦法但是沒有解決之後，再去問。
相同的問題不要問第二遍：每次問題解決完之後，把解決的過程記錄下來，避免相同的問題問多次，這是很讓別人討厭的事情。
多和同事交流：可能很多人聽過這樣的說法，同事不可能成為朋友的，其實不是這樣的，千萬不要進入一個團隊後，就“自閉”起來，也不交流工作以外的事情。建議大家還是能和周圍的同事“打成一片”，當你接觸的人多了，你會發現很多事情都非常好推進。
03. 獨當一面才算是真正的成長
我真正適應了職場工作，是在一次獨立出差之後，因為這代表了我有能力可以獨當一面了，雖然這一面是非常小的一面。
08 年出差去上海，也就是我的第一個項目要交付實施了，其實在開發測試過程中，我已經去過上海兩次了，不過以前都是跟著項目經理一起出差，而這次出差是我一個人來的；這一次我獨立支持客戶上線部署、生產環境驗證，在此過程中遇到的問題都是自己來解決，經此一役，我才覺得我自己真正地從學校的學生變成了公司的員工。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
從業餘程序員到職業程序員
程序員剛入行時，我覺得最重要的是把自己培養成職業的程序員。
我的程序員起步比同齡人都晚了很多，更不用說現在的年輕人了。我大學讀的是生物專業，在上大學前基本算是完全沒接觸過計算機。軍訓的時候因為很無聊，我和室友每天跑去學校的機房玩，我現在還印象很深刻，我第一次走進機房的時候，別人問，你是要玩windows，還是dos，我那是完全的一抹黑。後來就只記得在機房一堆人都是在練習盲打，軍訓完，盲打倒是練的差不多了，對計算機就這麼產生了濃厚的興趣，大一的時候都是玩組裝機，搗鼓了一些，對計算機的硬件有了那麼一些瞭解。
到大二後，買了一些書開始學習當時最火的網頁三劍客，學會了手寫HTML、PS的基本玩法之類的，課餘、暑假也能開始給人做做網站什麼的(那個時候做網站真的好賺錢)，可能那樣過了個一年左右，做靜態的網頁就不好賺錢了，也不好找實習工作，於是就開始學asp，寫些簡單的CRUD，做做留言板、論壇這些動態程序，應該算是在這個階段接觸編程了。
畢業後加入了深圳的一家做政府行業軟件的公司，一個非常靠譜和給我空間的Leader，使得自己在那幾年有了不錯的成長，終於成了一個職業的程序員。
通常來說，業餘或半職業的程序員，多數是1個人，或者很小的一個團隊一起開發，使得在開發流程、協作工具（例如jira、cvs/svn/git等）、測試上通常會有很大的欠缺，而職業的程序員在這方面則會專業很多。另外，通常職業的程序員做的系統都要運行較長的時間，所以在可維護性上會特別注意，這點我是在加入阿里後理解更深的。一個運行10年的系統，和一個寫來玩玩的系統顯然是有非常大差別的。
這塊自己感覺也很難講清楚，只能說模模糊糊有個這樣的概念。通常在有興趣的基礎上，從業餘程序員跨越到成為職業程序員我覺得不會太難。
編程能力的成長
作為程序員，最重要的能力始終是編程能力，就我自己的感受而言，我覺得編程能力的成長主要有這麼幾個部分：
1、編程能力初級：會用
編程，首先都是從學習編程語言的基本知識學起的，不論是什麼編程語言，有很多共同的基本知識，例如怎麼寫第一個Hello World、if/while/for、變量等，因此我比較建議在剛剛開始學一門編程語言的時候，看看編程語言自己的一些文檔就好，不要上來就去看一些高階的書。我當年學Java的時候上來就看Think in Java、Effective Java之類的，真心好難懂。
除了看文檔以外，編程是個超級實踐的活，所以一定要多寫代碼，只有這樣才能真正熟練起來。這也是為什麼我還是覺得在面試的時候讓面試者手寫代碼是很重要的，這個過程是非常容易判斷寫代碼的熟悉程度的。很多人會說由於寫代碼都是高度依賴IDE的，導致手寫很難，但我絕對相信寫代碼寫了很多的人，手寫一段不太複雜的、可運行的代碼是不難的。即使像我這種三年多沒寫過代碼的人，讓我現在手寫一段不太複雜的可運行的Java程序，還是沒問題的，前面N年的寫代碼生涯使得很多東西已經深入骨髓了。
我覺得編程能力初級這個階段對於大部分程序員來說都不會是問題，勤學苦練，是這個階段的核心。
2、編程能力中級：會查和避免問題
除了初級要掌握的會熟練的使用編程語言去解決問題外，中級我覺得首先是提升查問題的能力。
在寫代碼的過程中，出問題是非常正常的，怎麼去有效且高效的排查問題，是程序員群體中通常能感受到的大家在編程能力上最大的差距。
解決問題能力強的基本很容易在程序員群體裡得到很高的認可。在查問題的能力上，首先要掌握的是一些基本的調試技巧，好用的調試工具，在Java裡有JDK自帶的jstat、jmap、jinfo，不在JDK裡的有mat、gperf、btrace等。工欲善其事必先利其器，在查問題上是非常典型的，有些時候大家在查問題時的能力差距，有可能僅僅是因為別人比你多知道一個工具而已。
除了調試技巧和工具外，查問題的更高境界就是懂原理。一個懂原理的程序員在查問題的水平上和其他程序員是有明顯差距的。我想很多的同學應該能感受到，有些時候查出問題的原因僅僅是因為有效的工具，知其然不知其所以然。
我給很多阿里的同學培訓過Java排查問題的方法，在這個培訓裡，我經常也會講到查問題的能力的培養最主要的也是熟練，多嘗試給自己寫一些會出問題的程序，多積極的看別人是怎麼查問題的，多積極的去參與排查問題，很多最後查問題能力強的人多數僅僅是因為“無他，但手熟爾”。
我自己排查問題能力的提升主要是在2009年和2010年。那兩年作為淘寶消防隊（處理各種問題和故障的虛擬團隊）的成員，處理了很多的故障和問題。當時消防隊還有阿里最公認的技術大神——多隆，我向他學習到了很多排查問題的技巧。和他比，我排查問題的能力就是初級的那種。
印象最深刻的是一次我們一起查一個應用cpu us高的問題，我們兩定位到是一段代碼在某種輸入參數的時候會造成cpu us高的原因後，我能想到的繼續查的方法是去生產環境抓輸入參數，然後再用參數來本地debug看是什麼原因。但多隆在看了一會那段代碼後，給了我一個輸入參數，我拿這個參數一運行，果然cpu us很高！這種case不是一次兩次。所以我經常和別人說，我是需要有問題場景才能排查出問題的，但多隆是完全有可能直接看代碼就能看出問題的，這是本質的差距。
除了查問題外，更厲害的程序員是在寫代碼的過程就會很好的去避免問題。大家最容易理解的就是在寫代碼時處理各種異常情況，這裡通常也是造成程序員們之間很大的差距的地方。
寫一段正向邏輯的代碼，大部分情況下即使有差距，也不會太大，但在怎麼很好的處理這個過程中有可能出現的異常上，這個時候的功力差距會非常明顯。很多時候一段代碼裡處理異常邏輯的部分都會超過正常邏輯的代碼量。
我經常說，一個優秀程序員和普通程序員的差距，很多時候壓根就不需要看什麼滿天飛的架構圖，而只用show一小段的代碼就可以。
舉一個小case大家感受下。當年有一個嚴重故障，最後查出的原因是輸入的參數裡有一個是數組，把這個數組裡的值作為參數去查數據庫，結果前面輸入了一個很大的數組，導致從數據庫查了大量的數據，內存溢出了，很多程序員現在看都會明白對入參、出參的保護check，但類似這樣的case我真的碰到了很多。
在中級這個階段，我會推薦大家儘可能的多刻意的去培養下自己這兩個方面的能力，成為一個能寫出高質量代碼、有效排查問題的優秀程序員。
3、編程能力高級：懂高級API和原理
就我自己的經歷而言，我是在寫了多年的Java代碼後，才開始真正更細緻的學習和掌握Java的一些更高級的API，我相信多數Java程序員也是如此。
我算是從2003年開始用Java寫商業系統的代碼，但直到在2007年加入淘寶後，才開始非常認真地學習Java的IO通信、併發這些部分的API。儘管以前也學過也寫過一些這樣的代碼，但完全就是皮毛。當然，這些通常來說有很大部分的原因會是工作的相關性，多數的寫業務系統的程序員可能基本就不需要用到這些，所以導致會很難懂這些相對高級一些的API，但這些API對真正的理解一門編程語言，我覺得至關重要。
在之前的程序員成長路線的文章裡我也講到了這個部分，在沒有場景的情況下，只能靠自己去創造場景來學習好。我覺得只要有足夠的興趣，這個問題還是不大的，畢竟現在有各種開源，這些是可以非常好的幫助自己創造機會學習的，例如學Java NIO，可以自己基於NIO包一個框架，然後對比Netty，看看哪些寫的是不如Netty的，這樣會非常有助於真正的理解。
在學習高級API的過程中，以及排查問題的過程中，我自己越來越明白懂編程語言的運行原理是非常重要的，因此我到了後面的階段開始學習Java的編譯機制、內存管理、線程機制等。對於我這種非科班出身的而言，學這些會因為缺乏基礎更難很多，但這些更原理性的東西學會了後，對自己的編程能力會有質的提升，包括以後學習其他編程語言的能力，學這些原理最好的方法我覺得是先看看一些講相關知識的書，然後去翻看源碼，這樣才能真正的更好的掌握，最後是在以後寫代碼的過程中、查問題的過程中多結合掌握的原理，才能做到即使在N年後也不會忘。
在編程能力的成長上，我覺得沒什麼捷徑。我非常贊同1萬小時理論，在中級、高級階段，如果有人指點或和優秀的程序員們共事，會好非常多。不過我覺得這個和讀書也有點像，到了一定階段後（例如高中），天分會成為最重要的分水嶺，不過就和大部分行業一樣，大部分的情況下都還沒到拼天分的時候，只需要拼勤奮就好。
系統設計能力的成長
除了少數程序員會進入專深的領域，例如Linux Kernel、JVM，其他多數的程序員除了編程能力的成長外，也會越來越需要在系統設計能力上成長。
通常一個編程能力不錯的程序員，在一定階段後就會開始承擔一個模塊的工作，進而承擔一個子系統、系統、跨多領域的更大系統等。
我自己在工作的第三年開始承擔一個流程引擎的設計和實現工作，一個不算小的系統，並且也是當時那個項目裡的核心部分。那個階段我學會了一些系統設計的基本知識，例如需要想清楚整個系統的目標、模塊的劃分和職責、關鍵的對象設計等，而不是上來就開始寫代碼。但那個時候由於我是一個人寫整個系統，所以其實對設計的感覺並還沒有那麼強力的感覺。
在那之後的幾年也負責過一些系統，但總體感覺好像在系統設計上的成長沒那麼多，直到在阿里的經歷，在系統設計上才有了越來越多的體會。（點擊文末閱讀原文，查看：我在系統設計上犯過的14個錯，可以看到我走的一堆的彎路）。
在阿里有一次做分享，講到我在系統設計能力方面的成長，主要是因為三段經歷，負責專業領域系統的設計 - 負責跨專業領域的專業系統的設計 - 負責阿里電商系統架構級改造的設計。
第一段經歷，是我負責HSF。HSF是一個從0開始打造的系統，它主要是作為支撐服務化的框架，是個非常專業領域的系統，放在整個淘寶電商的大系統來看，其實它就是一個很小的子系統，這段經歷裡讓我最深刻的有三點：
1).要設計好這種非常專業領域的系統，專業的知識深度是非常重要的。我在最早設計HSF的幾個框的時候，是沒有設計好服務消費者/提供者要怎麼和現有框架結合的，在設計負載均衡這個部分也反覆了幾次，這個主要是因為自己當時對這個領域掌握不深的原因造成的;
2). 太技術化。在HSF的階段，出於情懷，在有一個版本里投入了非常大的精力去引進OSGi以及去做動態化，這個後來事實證明是個非常非常錯誤的決定，從這個點我才真正明白在設計系統時一定要想清楚目標，而目標很重要的是和公司發展階段結合；
3). 可持續性。作為一個要在生產環境持續運行很多年的系統而言，怎麼樣讓其在未來更可持續的發展，這個對設計階段來說至關重要。這裡最low的例子是最早設計HSF協議的時候，協議頭裡竟然沒有版本號，導致後來升級都特別複雜；最典型的例子是HSF在早期缺乏了缺乏了服務Tracing這方面的設計，導致後面發現了這個地方非常重要後，全部落地花了長達幾年的時間；又例如HSF早期缺乏Filter Chain的設計，導致很多擴展、定製化做起來非常不方便。
第二段經歷，是做T4。T4是基於LXC的阿里的容器，它和HSF的不同是，它其實是一個跨多領域的系統，包括了單機上的容器引擎，容器管理系統，容器管理系統對外提供API，其他系統或用戶通過這個來管理容器。這個系統發展過程也是各種犯錯，犯錯的主要原因也是因為領域掌握不深。在做T4的日子裡，學會到的最重要的是怎麼去設計這種跨多個專業領域的系統，怎麼更好的劃分模塊的職責，設計交互邏輯，這段經歷對我自己更為重要的意義是我有了做更大一些系統的架構的信心。
第三段經歷，是做阿里電商的異地多活。這對我來說是真正的去做一個巨大系統的架構師，儘管我以前做HSF的時候參與了淘寶電商2.0-3.0的重大技術改造，但參與和自己主導是有很大區別的，這個架構改造涉及到了阿里電商眾多不同專業領域的技術團隊。在這個階段，我學會的最主要的：
1). 子系統職責劃分。在這種超大的技術方案中，很容易出現某些部分的職責重疊和衝突，這個時候怎麼去劃分子系統，就非常重要了。作為大架構師，這個時候要從團隊的職責、團隊的可持續性上去選擇團隊；
2). 大架構師最主要的職責是控制系統風險。對於這種超大系統，一定是多個專業領域的架構師和大架構師共同設計，怎麼確保在執行的過程中對於系統而言最重要的風險能夠被控制住，這是我真正的理解什麼叫系統設計文檔裡設計原則的部分。
設計原則我自己覺得就是用來確保各個子系統在設計時都會遵循和考慮的，一定不能是虛的東西，例如在異地多活架構裡，最重要的是如何控制數據風險，這個需要在原則裡寫上，最基本的原則是可接受系統不可用，但也要保障數據一致，而我看過更多的系統設計裡設計原則只是寫寫的，或者千篇一律的，設計原則切實的體現了架構師對目標的理解（例如當時異地多活這個其實開始只是個概念，但做到什麼程度才叫做到異地多活，這是需要解讀的，也要確保在技術層面的設計上是達到了目標的），技術方案層面上的選擇原則，並確保在細節的設計方案裡有對於設計原則的承接以及執行；
3). 考慮問題的全面性。像異地多活這種大架構改造，涉及業務層面、各種基礎技術層面、基礎設施層面，對於執行節奏的決定要綜合考慮人力投入、機器成本、基礎設施佈局訴求、穩定性控制等，這會比只是做一個小的系統的設計複雜非常多。
系統設計能力的成長，我自己覺得最重要的一是先在一兩個技術領域做到專業，然後儘量擴大自己的知識廣度。例如除了自己的代碼部分外，還應該知道具體是怎麼部署的，部署到哪去了，部署的環境具體是怎麼樣的，和整個系統的關係是什麼樣的。
像我自己，是在加入基礎設施團隊後才更加明白有些時候軟件上做的一個決策，會導致基礎設施上巨大的硬件、網絡或機房的投入，但其實有可能只需要在軟件上做些調整就可以避免，做做研發、做做運維可能是比較好的把知識廣度擴大的方法。
第二點是練習自己做tradeoff的能力，這個比較難，做tradeoff這事需要綜合各種因素做選擇，但這也是所有的架構師最關鍵的，可以回頭反思下自己在做各種系統設計時做出的tradeoff是什麼。這個最好是親身經歷，聽一些有經驗的架構師分享他們選擇背後的邏輯也會很有幫助，尤其是如果恰好你也在同樣的挑戰階段，光聽最終的架構結果其實大多數時候幫助有限。
技術Leader我覺得最好是能在架構師的基礎上，後續注重成長的方面還是有挺大差別，就不在這篇裡寫了，後面再專門來寫一篇。
程序員金字塔
我認為程序員的價值關鍵體現在作品上，被打上作品標籤是一種很大的榮幸，作品影響程度的大小我覺得決定了金字塔的層次，所以我會這麼去理解程序員的金字塔。
當然，要打造一款作品，僅有上面的兩點能力是不夠的，作品裡很重要的一點是對業務、技術趨勢的判斷。
希望作為程序員的大夥，都能有機會打造一款世界級的作品，去為技術圈的發展做出貢獻。
由於目前IT技術更新速度還是很快的，程序員這個行當是特別需要學習能力的。我一直認為，只有對程序員這個職業真正的充滿興趣，保持自驅，才有可能在這個職業上做好，否則的話是很容易淘汰的。
作者：畢玄，2007年加入阿里，十多年來主要從事在軟件基礎設施領域，先後負責阿里的服務框架、Hbase、Sigma、異地多活等重大的基礎技術產品和整體架構改造。
51CTO
我剛進入公司時對Java是一竅不通，現在也已經是擁有多年經驗的資深Java開發了，說說我的經歷吧，希望能對你有所幫助。
我是以Android開發的身份進入第一家公司的，由於公司那段時間沒有進行中的Android項目，所以讓我轉了Java Web開發，當時我的處境可比你慘多啦，Web開發我可以說是一竅不通啊，而且那時候還不流行前後端分離，一個人既要寫後端又要寫頁面，同時還要兼顧數據庫設計等其他的一大堆工作。項目代碼拿到手，幾乎是看不懂，連基本的項目結構都搞不清楚，那麼我是怎麼做到快速熟悉項目的呢？
主動學習
首先要做到的就是主動學習，把項目中用到的技術點列出來，不會的自己一定要去主動學習。
作為程序員，我相信找文檔、查資料的本領還是有的吧，那麼我們可以適當利用一下晚上的休息時間來學習，不要怕辛苦。特別強調一點，學習的時候一定要自己動手去實踐，這樣知識點才能掌握牢固。
臉皮要厚
其次要做到的就是臉皮要厚，對項目中任何有疑問的地方，及時向其他同事請教，千萬不要愛面子而不好意思問。
新人剛進公司臉皮薄，加上同事之間不怎麼熟悉，所以遇到問題不好意思問，自己一個人在那瞎折騰，最後時間花了還走了彎路。
提問的技巧
前面雖然說了臉皮要厚，遇到問題要及時提問，但是呢有一個前提，一定要帶著自己的思考提問。
遇到問題，首先要自己嘗試解決，解決不了的再向同事提問，提問時可以說說自己的思路，再把不明白的點和同事一點探討，這樣對於問題才會有一個更加深刻的理解。
總結
要想快速熟悉公司項目，先列出項目中用到的技術點，首先對於不會的技術進行針對性的學習，其次有疑問要多向同事提問，同時提問一定要帶有自己的思考。
代碼那些事兒
作為同行，算不上前輩，僅僅比你多工作了兩年時間，剛入公司做項目時也很迷茫，看不懂，連從哪下手都不知道，著急入手所以直接一行一行去讀別人代碼，遇到不知道的技術就去百度，雖然效率低下但是總比沒有進展強，現在回頭想想其實當時挺蠢的，我們要明白技術主要是為了實現業務，無非就是對幾個表的增刪改查，不會寫增刪改查沒關係，我們不要看到不會的就立馬去查去百度，那樣我們就會迷失在代碼裡面，永遠走不出來。最簡單的入門就是你找到一個最近簡單的業務，這個你可以問產品，問技術，大家應該都會說，順著這個業務去跟代碼，你就會很容易找到入口和出口，理解代碼的速度就會更快
烏魯奇奧拉湮
感謝題主的邀請，鑑於題主的問題是很多代碼看不懂，我以前是按照以下方法做的。
我當初進入一個公司，都是先不急著看代碼，先花個2天把公司項目的需求，接口文檔，業務邏輯自己過一遍。
題主雖然是一個實習生，但是也要有緊迫感。10年前我才出來擼代碼的時候，都是時刻擔心被炒。畢竟公司不是慈善機構，對我們都有考核期。你要儘快把需求，接口文檔把業務邏輯走一遍。
善於做筆記，哪裡不懂的要記錄下來，遇到核心不懂的代碼，就問技術負責人。問他的時候最好是一次性問，而且要問有價值的問題。因為問多了別人也煩。我當初是深有感觸。
不懂得代碼通過搜索引擎，Stackoverflow或者CSDN論壇去找答案
你不懂的代碼。你要自己多嘗試去通過搜索引擎去解決。看看這個框架怎麼介紹的，以及如何使用。其實搜索引擎能解決我們日常工作的大部分問題。
通過自己Debug調試去熟悉代碼
看代碼不能就一直盯著代碼看。你要動手實踐，通過代碼斷點調試去看代碼。多看看代碼的註釋，我想很多核心功能都會有註釋的。如果代碼能拷貝回去，晚上回家了也加加班，多研究代碼。
多跟熟悉產品的同事交流
多與公司的銷售，設計，產品經理，測試交流。我想測試跟產品就是個”活文檔“，他們能讓你快速的瞭解公司的產品，對你熟悉代碼有很大的幫助。
加入一些技術群，裡面一般都有大佬的
你可以加入一些技術群。不懂的代碼，你可以問群裡的大佬，哪怕是有償的也可以。但是有些代碼涉及到公司的機密，您注意把握這方面的尺度就好了。對於大佬告訴了你的答案，你一定要弄清楚裡面的邏輯
上班時間努力熟悉代碼，下班了晚上回去了，業餘時間可以買相關書籍資料看
個人建議：
題主有危機感的同時也不要太過著急。我想技術官既然把你招進來了，說明你還是得到公司的認可了的。其次我認為，想要徹底把整個項目完全弄懂是不可能的。畢竟是接手別人的項目。但是隻要你能通過斷點調試找到核心代碼的地方，不影響您日常開發就好了。加油！我相信通過以上方法再加上您的努力肯定會很快熟悉代碼的。
胖子李愛互聯網
本人10年開發培訓經驗,期間經歷了Java Web,Android,H5,大數據,PHP等多個不同的方向的開發,也做過軟件培訓公司的金牌講師，很有興趣回答你這個問題。
你現在實習的過程中碰見的這種茫然狀態，是很多新人剛入行時候的一個常見現象。造成這個問題的原因，有這麼幾點吧。
1.技能不足
你目前主流的框架掌握的是SSH，目前SSH這套組合其實已經比較陳舊了，尤其是在一線城市，新項目基本不會採用SSH組合了，最次也得SSM，一般都會上SpringBoot，或者SpringCloud，然後技術儲備豐厚的公司，往往都採用自己的框架了。你們公司就有特別的ext，所以你學習的技術得與公司的需求保持一致。
2.項目經驗不夠
剛從學校出來，可能也做過一些小型的項目，但是碰見實際的大型的項目，光是看代碼可能都覺得頭大，更不能很快的理順項目思路，不知道從哪裡下手。別人的代碼也看不懂，也不知道該怎麼梳理項目思路等。
3.業務不熟悉
對自己公司的項目，具體的業務也不夠熟悉，不是很明確的瞭解項目中各個功能，業務之間的關係，具體該怎麼一個處理流程不夠熟悉，也會造成這個茫然的問題。
4.工具不熟悉
開發過程中需要使用很多的開發工具，尤其是團隊協作，新手常見的問題就是SVN，Git這樣的工具使用不熟練，不敢用，害怕把別人的代碼一下子給弄壞了，經常提心吊膽的狀態。
5.環境不熟悉
剛到一個新的公司，公司的環境，人員都不熟悉，碰見了問題也不知道問誰，也不敢去打擾別人，害怕別人批評自己等。
6.其他因素
可能還有其他一些因素，會導致一個實習生剛進公司的時候比較茫然，工作不能很順利的開展。
說了這麼多因素，那麼如何解決呢？解決辦法可以參考如下：
1.多與同事交流
作為一個新人，尤其是實習生，不熟悉業務，不熟悉技能是正常的，大家也都知道這一點。所以不用害怕露怯，那麼就大膽的去問你的領導，問你的師傅，即使讓人家懟幾句，也無所謂，把自尊心調整的”大條“一點！
2.快速融入環境
與同事儘快熟悉起來，搞好個人關係，碰見男同事就散煙，碰見女同事就請喝奶茶，多幫別人跑跑腿，你和別人關係好了，遇到問題別人才願意幫你！
3.加強技術學習
最重要的是你得加強自己的技術能力，項目中涉及到的技術，自己回到家就多鑽研多學習，網上應該有很多資料，去下載學習。技術實力提升了，這樣工作的時候，碰見的小問題就自己解決了，不能事事麻煩別人。
4.多加班
既然自己短期內無法快速解決問題，那就多付出點時間唄，別一下班就急著回家，你領導看見你這樣也不喜歡啊，新人就要多表現。
希望以上的回答可以解決你的問題吧！
我從事互聯網開發10年，主要的研究方向集中在Java web微服務架構領域,Android移動端研發,HTML5前端方向，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信你一定會有所收穫。
如果有Java,Android,H5等開發方面的問題，或者是開發求職方面的問題，都可以在評論區留言，或者私信我。
一一哥Sun
算不上前輩們，只能說是多吃了兩年飯。新人剛入行可能會手忙腳亂，什麼都不會，不用慌張，這些都是正常的。
第一個建議就是多跟同事熟悉瞭解，不要自顧高冷，這對你沒好處，嘴巴甜一點，勤快些，自己有啥問題他們也願意幫你回答，畢竟你是應屆生，不會是正常的。
第二條建議就是凡事務必先百度、谷歌，你在編程中所能遇到的99.9%的問題，搜索引擎都能給你解決，剩下的才能去問同事啥的，要儘量避免問別人，因為別人也有事，不可能一天被你大段時間還心平氣和。
第三條就是要能坐得下冷板凳，編程技術都是苦熬出來的，除了必要的工作，私底下也要不斷的學習，要隨時瞭解自己行業的最新技術變化，緊跟著變化。個人建議多關注一些質量高的公眾號、學習網站等。
配圖是安卓開發的[捂臉]，本人安卓開發
我叫陳壯士
我一直用的幾招，可以分享。
首先把這個信息管理系統大致瞭解下，至少做到看到頁面或功能時，知道代碼大致在哪個地方。以及公共部分的庫，接口。
一般不會把整個項目都讓你接手。所以重點就落在你接手的那部分了。這就需要每一行一行地去看，要是有註釋還好，沒有註釋的話，日誌、輸出、斷點都要試試。要深入理解。
如果以上兩步你都能做到，那麼恭喜你，你可以開始修改之前留下的BUG或者需要優化的部分。
李老師tome
入行時，新單位對要開發的項目的認知還非常不圓滿。原來的負責任，很快就調任其他工作了。
1、Extjs是Sencha的那個產品嗎？你說的“整個”有點模糊，什麼意思？
2、Sencha的ExtJS是付費的用戶嗎？什麼版本？
搞清這幾點，其他就簡單了。
ExtJS傾向於獨佔“整個項目”。這個可以接受，就可以開工了。
a、用途ExtJS的組件，設計（紙面畫圖）、實現所有的用戶功能（前端可視冰點）和操作流程。
b、用ExtJS實現（a）的前端設計。
c、逐一搞定“前端”需要的“數據源”。
做好了（a、），（b、）的開發可以並行展開。（c、）需要多請教前輩，如果在開始（a、）的工作前，對現有數據庫（所謂“整合”的原因？）系統有所瞭解的話，會有事半功倍的效果。
