一年一度的金三銀四跳槽大戲即將落幕，相信很多跳槽的小夥伴們已經找到了心儀的工作，即將或已經有了新的開始。
相信有過跳槽經驗的小夥伴們都知道，每到一個新的公司面臨的可能都是新的業務、新的技術、新的團隊......這些可能會打破你原來工作思維、編碼習慣、合作方式......
而於公司而言，又不能給你幾個月的時間去慢慢的熟悉。這個時候，如何快速進入工作狀態，儘快發揮自己的價值是非常重要的。
有些人可能會很幸運，入職的公司會有完善的流程與機制，通過一帶一、各種培訓等方式可以在短時間內快速的讓新人進入工作狀態。有些人可能就沒有那麼幸運了，就比如我在幾年前跳槽進入某廠的時候，當時還沒有像我們現在這麼完善的帶新人融入的機制，又趕上團隊最忙的一段時間，剛一入職的當天下午就讓給了我幾個線上問題去排查，也沒有任何的文件和培訓。遇到情況，很多人可能會因為難以快速適應，最終承受不起壓力而萌生退意。
那麼我們應該如何去快速的讓自己進入工作狀態，適應新的工作節奏呢？
新的工作面對著一堆的程式碼倉庫，很多人常常感覺無從下手。但回顧一下自己過往的工作與專案的經驗，我們可以發現它們有著異曲同工之處。當開始一個新的專案，一般會經歷幾個步驟：需求->設計->開發->測試->釋出，就這麼迴圈往復，我們完成了一個又一個的專案。
而在這個過程中主要有四個方面的知識那就是業務、技術、專案與團隊貫穿始終。新入職一家公司，我們第一階段的目標就是要具備能夠跟著團隊做專案的能力，因此我們所應儘快掌握的知識點也要從這四個方面入手。
業務
很多人可能會認為作為一個技術人，最應該瞭解的不應該是技術嗎？於是他們在進入一家公司後，就迫不及待的研究起來了一些技術文件，系統架構，甚至抱起來原始碼就開始“啃”，如果你也是這麼做的，那就大錯特錯了！在幾乎所有的公司裡，技術都是作為一個工具存在的，雖然它很重要，但是它也是為了承載業務所存在的，技術解決了如何做的問題，而業務卻告訴我們，做什麼，為什麼做。一旦脫離了業務，那麼技術的存在將毫無意義。
想要了解業務，有兩個非常重要的方式
一是靠問
如果你加入的團隊，有著完善的業務培訓機制，詳盡的需求文件，也許你不需要過多的詢問就可以瞭解業務，但這只是理想中的情況，大多數公司是沒有這個條件的。因此我們只能靠問。
這裡不得不提的是，作為一個新人一定要有一定的臉皮厚度，不懂就要問。我見過很多新人會因為內向、靦腆，遇到疑問總是不好意思去問，這導致他們很長一段時間都難以融入團隊、承擔更重要的責任。不怕要怕挨訓、怕被懟，而且我相信絕對多數的程式設計師還是很好溝通的！
二是靠測試
我認為測試絕對是一個人快速瞭解團隊業務的方式。通過測試我們可以走一走自己團隊所負責專案的整體流程，如果遇到自己走不下去或想不通的地方及時去問，在這個過程中我們自然而然的就可以快速的瞭解到核心的業務流程。
在瞭解業務的過程中，我們應該注意的是不要讓自己過多的去追求細節，我們的目的是先能夠整體瞭解業務流程，我們面向哪些使用者，提供了哪些服務......
技術
在我們初步瞭解完業務之後，就該到技術了，也許你已經按捺不住翻開原始碼的準備了，但還是要先提醒你一句先不要著急。
這個時候我們應該先按照自己瞭解到的業務，結合自己過往的工作經驗去思考一下如果是自己去實現這個系統，應該如何去做？這一步很重要，它可以在後面我們具體去了解系統的技術實現的時候去對比一下與自己的實現思路有哪些差異，為什麼會有這些差異，哪些更好，哪些不好，對於不好我們可以提出自己的意見，對於更好的我們可以吸收學習為己用！
接下來，我們就是要了解技術了，但也不是一上來就去翻原始碼。應該按照從巨集觀到細節，由外而內逐步地對系統進行分析。
首先我們應該簡單的瞭解一下自己團隊的所用到的技術棧，Java還是.NET、亦或是多種語言並存，專案是前後端分離還是服務端全包，使用的資料時MYSQL還是MSSQL......，這樣我們可能會對所用到的技術和框架，以及自己所負責的內容有一定的預期，這一點有的人可能在面試的時候就會簡單瞭解過。
下一步我們應該瞭解的是系統的巨集觀業務架構。自己的團隊主要負責哪些系統，每個系統又主要包含哪些模組，又與哪些外部系統進行互動......對於這些，最好可以通過流程圖或者思維導圖等方式整理出來。
然後我們要做的是看一下自己的團隊提供了哪些對外的介面或者服務。每個介面和服務所提供功能是什麼。這一點我們可以繼續去測試自己的系統，這個時候我們要看一看主要流程中主要包含了哪些頁面，每個頁面又呼叫了後端的哪些介面，每個後端介面又對應著哪個程式碼倉庫。(如果是單純做後端服務的，可以看一下我們提供了哪些服務，又有哪些上游服務，每個上游服務呼叫自己團隊的哪些服務......)，同樣我們應該用畫圖的形式整理出來。
接著我們要了解一下自己的系統或服務又依賴了哪些外部服務，也就是說需要哪些外部系統的支援，這些服務也許是團隊之外、公司之外，也可能是其他公司提供的。這個時候我們可以簡單的進入程式碼看一下與外部系統的互動是怎麼做的，包括通訊框架(REST、RPC)、通訊協議......
到了程式碼層面，我們首先應該瞭解每個模組程式碼的層次結構，一個模組分了多少層，每個層次的職責是什麼，瞭解了這個就對系統的整個設計有了初步的概念，緊接著就是程式碼的目錄結構、配置檔案的位置。
最後我們可以尋找一個示例，可以是一個介面，一個頁面，讓我們的思路跟隨者程式碼的執行的路線，從入參到出參，完整的走一遍來驗證一下我們之前的瞭解。
到了這裡我們對於技術層面的瞭解就可以先告一段落了，我們的目的知識對系統有一個初步的認知，更細節的東西，後面我們會有大把的時間去了解
專案與團隊
上面我們提到，新入職一家公司，第一階段的目標是有跟著團隊做專案的能力，接下來我們要了解的就是專案是如何運作的。
我們應該把握從需求設計到程式碼編寫入庫最終到釋出上線的整個過程中的一些關鍵點。例如專案採用敏捷還是瀑布的模式，一個迭代週期是多長，需求的來源以及展現形式，有沒有需求評審，程式碼的編寫規範是什麼，編寫完成後如何構建，如何入庫，有沒有提交規範，如何交付測試，釋出前的準備是什麼，釋出工具如何使用......
關於專案我們只需要觀察同事，或者自己親身經歷一個迭代的開發，就能夠大概瞭解清楚。
在瞭解專案運作的同時，我們還應該去了解團隊，同樣我們應該先從外部開始，我們對接了哪些外部團隊，比如需求從哪裡來，是否對接公司外部的團隊，提供服務的上游團隊有哪些，依賴的下游團隊有哪些，團隊之間如何溝通，常用的溝通方式是什麼.......
接下來則是團隊內部，團隊中有哪些角色，每個人的職責是什麼，這樣遇到問題我們也可以清楚的找到對應的同事尋求幫助。是否有一些定期的活動與會議，例如每日站會、周例會，是否有一些約定俗成的規矩，是否有一些內部評審，分享機制......
總結
新入職一家公司，面臨新的工作挑戰，能夠儘快進入工作狀態，實現自己的價值，將會給你帶來一個好的開始。
作為一個程式設計師，能夠儘快進入工作狀態，意味著我們首先應該具備跟著團隊做專案的能力，這裡我站在了一個後端開發的角度上從業務、技術、專案與團隊四個方面總結了一些方法和經驗。
關於如何快速進入工作狀態，如果你有好的方法與建議，歡迎在評論區留言。
最後我們用一張思維導圖來回顧一下這篇文章的內容。如果你覺得這篇文章對你有所幫助，可以關注文末公眾號，我會經常分享一些自己成長過程中的經驗與心得，與大家一起學習與進步。
