加入新公司,怎樣快速熟悉業務和專案?
很多新人進入一家新公司後,最頭疼的就是如何快速瞭解公司的業務和專案架構,或者說不要求快速,即便有足夠的時間,也很難在龐大的業務中整理出思緒。當然,如果你碰到一個特別熱心的老員工,事無鉅細地給你講,隨時在你身邊答疑解惑,那可能還好。
但很可惜,我沒有碰到這樣的人,在加入新公司後,帶我的人幾乎沒花時間給我講專案,也沒給我安排可以熟悉專案的任務。
就這樣的一個多月時間裡,我慢慢靠自己的力量熟悉了大概十個專案,並在過程中總結了一些方法,藉此機會記錄一下,分享給大家。
首先在這裡強調一點,我的策略 不是快速瞭解一個專案的具體業務,因為這個不同專案也不一樣,無法總結。我的策略是大體瞭解整個業務線上的所有專案,大概摸清楚每個專案都是幹嘛的,它們之間的關係如何,以便以後不論具體負責哪個專案都不至於找不到方向。
這樣等到需要負責具體到細節的業務時,雖然依然需要花時間,但相比整體一頭霧水地開始,還是簡單許多的。
一、必要條件
我們首先要想的是,有了哪些必要條件後,給你足夠的時間,你才能夠完全瞭解整個專案?
這裡說的必要條件不是“專案面對的客戶是誰”、“專案用的框架是什麼”這種,而是真真正正的必要條件,就好比用幾條數學公理能推出整個數學體系一樣。這裡我總結的真正的必要條件只有兩點:
-
原始碼位置(gitlab或svn);
-
部署環境(dev/test/online);
所謂專案,其實就是一堆程式碼放在了一堆機器上而已,所以這些就足夠了。
當然,為了更加節約時間,最好還要有wiki、jenkins、頁面訪問路徑、資料庫地址。
我之所以說那兩個是必要條件,是想說其實專案本質上就是這麼簡單的一個事,你千萬不要想的太複雜。 它的業務可以無限複雜,但它的本質卻逃不出這些,你千萬不可以糊塗。當你無從下手或者什麼都不清楚的時候,就主要把原始碼和環境弄清楚吧,其它的都是附屬品。
二、從頁面到資料庫的線
有了上面的必要條件後,我們就開始瞭解專案了。由於不只是一個專案,所以千萬不能深入具體程式碼,否則你就越來越煩直到放棄,也不會有好的效果。
對某個具體專案的瞭解,一定要建立在對整體瞭解的基礎上。這時我們首先為各個專案畫出一條線,並標明每一個節點的資訊,就像下面的樣子:
頁面訪問路徑——前端專案——後臺服務——資料庫地址
這裡的一個前端專案可能對應多個後臺服務,所以最終的圖應該差不多是這樣:
這個整理的過程,主要是讓自己梳理清楚,一共有哪些專案,哪些是前端可視的,哪些是後臺提供服務的,並且大致瞭解前端專案分別呼叫了哪些後臺服務。通過後臺服務和資料庫的名稱,我們能從本質上了解到這條業務線提供了什麼功能;從前端專案和頁面路徑,我們能瞭解到我們需要給使用者展示什麼。
注意,這個階段我們只是見名知意,即使點開頁面,連線上資料庫看看,也千萬別花過多的時間,因為這個階段的重點就是僅僅知道這條業務線提的整體內容。
在此基礎之上,這個圖可以不斷細化,比如專案部署的機器,我們可以標註在專案旁邊,或者儲存在Xshell裡。此外所有非業務相關的,能查到的儘量都記錄下來。這個真的為以後找各種東西提供太多方便了。如果不在這一步這樣做,別看你現在節約了時間,但等到以後查詢相關東西的時候,時間加起來將會是天文數字了。
這裡關於整理專案部署的機器還有個小插曲,跟大家分享一下。
由於這部分的資訊沒人會一個一個地告訴你,就算有也不可能說的特別全。所以我是藉助jenkins來整理的。專案部署都需要用到jenkins,只要檢視jenkins配置的命令,就可以把部署環境一一整理出來,這個我認為是最全而且最新的。
不要和我說查wiki,如果公司wiki都寫的這麼全,我估計就沒這篇文章什麼事了。當時我的jenkins許可權特別少,只能看一部分專案,而且還只能執行,不能看配置,帶我的人也是摳門,每次問他都給我開通所需要的專案的執行許可權,多一點都不給。後來我也懶得問了,由於jenkins機器大家都可以用root許可權登陸,所以我進入jenkins的配置檔案config.xml,給我自己添加了一個admin許可權,重啟jenkins,再開啟之後螢幕滿滿的專案都出來了,而且都可以檢視和修改,暢通無阻。我就這樣通過一個個jenkins的配置,整理了部署的機器,也看了下啟動的邏輯。
三、瞭解專案間的關係
這部分如果有老員工願意和你說說,那最好還是瞭解一下。如果沒有也沒關係,先跳過這段,以後慢慢了解也是可以的。
四、整理資料庫表
我們上面都是整理專案的大體框架,還沒有涉及到具體的專案細節。這一部分,仍然不去涉及。
如果說站在整個業務的本質上看,業務無非就是一堆程式碼執行在一堆機器上;那麼站在單個專案來看,一個專案無非就是對資料庫的增刪改查操作而已;或者從使用者的角度看,一個專案就是輸入一些引數得到一些返回結果而已。
所以接下來我們要做兩件事:一個是整理資料庫表,一個是整理Controller層的所有介面。
-
找核心專案: 這裡首先要選擇一個核心專案去看,眾多專案中一定有一個是核心專案,就先從這個開始看起。
-
篩選核心資料表: 如果資料庫的表比較少,那我們拿工具匯出來表結構,一個個看就行了,這個不難。但如果資料庫表特別多,我們首先要將表名全部匯出,篩選出那些核心的表。這裡匯出表名、篩選表以及後面的分析表字段,不妨給自己做個工具,我在遇到一些很麻煩的或者感覺以後還可以通用的事情時,就會做成一個小工具,放在一個我給自己起名為javamate的程式中,這些小工具逐漸積累起來你會發現今後有意想不到的方便。
-
判斷哪些是核心表: 不要著急,我們首先排除掉一些沒用的。拿我在公司分析的系統來說,一共150多個表,其中有好多copy結尾的是備份,flow結尾的是流水,rel結尾的是中間關聯表,statistics結尾的是資料統計表,log結尾的是日誌表,config結尾的是配置表,等等。排除掉這些對核心業務理解無影響的表之後,所剩的也就20來張表,再根據它們的名字,可以看出好多表是屬於一類的,比如order表就有各種order,按類別再分出來也就四五類,再分析起來就不難了。當然如果是更大的體系結構,那就要再不斷做拆解。
-
找出表之間的關係:在具體分析這些核心表字段之前,還要做一件事就是找出表中間的關係。如果表b中有個欄位,比如 叫 a.id,那麼b和a就是一對多的關係;如果兩個表有rel中間表,那二者就是多對多的關係,起碼從邏輯上講是這樣的。這個分析過程我也是做了個小工具,通過程式來判斷的。
到此,你就對整體的資料庫結構有所瞭解了。根據表名也能對錶的大致內容有所瞭解,接下來就是針對具體的表,看裡面具體的欄位和前人給出的備註,這個過程就沒有技巧了,要耐心,要慢慢熬。
五、整理Controller層介面
當對資料庫表做了以上的瞭解後,你基本上對這個系統能提供什麼服務瞭解得差不多了。這個時候不論你的程式碼長什麼樣子,資料庫擺在那裡,能提供的服務差不多就已經出來了,對有經驗的人來講,程式碼的業務邏輯也大致能猜到個八九分。
我們梳理了大後方,那接下來就是把最前端和別人互動的部分搞清楚,這樣掐頭去尾,整個專案就解剖的差不多了。
這裡我也給自己做了個小工具,掃描出所有的controller層的介面,展示出方法名、路徑名、引數列表和返回值等,但可惜沒能展示註釋,有大神有想法的話也歡迎幫我想想。
和資料庫一樣,如果介面很少,那麼一個個看;如果特別多,還是先找出比較核心的幾個方法研究。
這裡我用的是postman,把要研究的介面訪問儲存起來,並且新增訪問成功和失敗的Example。我推薦自己開發的時候也把postman用起來,越詳細越好,postman不只是可以簡簡單單訪問你的介面,還能做批量測試,還可以生成api文件用於和前端互動。這樣你不但測試了自己的介面,還省的寫文件了。而且postman還有個好處就是可以給自己的介面mock一個服務,這樣即使你的介面掛了,或者介面根本就沒寫好,也可以讓前端人員先訪問你的mock,完全不影響前端邊測試邊開發,這才是真正的前後端分離嘛。
六、重新理清專案間的關係
好了,這時候每個專案你已經大致瞭解,最起碼呼叫的效果,資料庫所能提供的服務,你是清楚的。至此,就要重新整理下專案之間的關係了。
-
根據之前的介面名稱,詳細瞭解下專案間的呼叫關係。理不清的部分去問老員工,這時候你帶著自己的瞭解問,他們也能給出更多的資訊。
-
看看每個專案中用到的中介軟體,主要是mq服務,看看誰是生產者,誰是消費者,以此來了解關係。
-
這時你應該已經開了好幾輪的週會了,接下來的週會你應該能聽懂部分內容。根據每個人的描述和最新的幾組需求,逐漸摸清楚現在專案面臨的問題,以及哪個專案是核心,哪個專案是輔助,哪個專案是以穩定安全為主的。
到此為止,你對整條業務線就有了大致的瞭解,接下來就可以結合你具體負責的內容、領導安排你做的方向,去看具體的業務程式碼了。
雖然之後的步驟依然需要你深入其中,事無鉅細地瞭解具體內容, 但此時,你通過前面的努力,已經可以站在一定的高度看每一個專案了,雖然你細節上還是不瞭解,但這是完全不同的。
在研究具體業務程式碼的同時,不斷地跳出來看整條業務線的框架,修正之前由於不瞭解具體業務而理解錯誤的架構。
長此以往,你一定會在某個專案中脫穎而出,讓大家認識到你的全域性視野,這也是走出老是寫增刪改查程式碼怪圈的一個途徑。慢慢會有人意識到,你對專案的理解總能站在全域性的視野,很多需要跨專案去做的業務,也會自然而然想到你,慢慢地,你會接觸到更為核心的東西,成為架構師,或者去轉向產品,轉向管理。
這就是我總結的瞭解專案的過程,我工作年限不多,經驗上還不夠豐富,希望大佬們多多留言指點,提出問題,共同進步。
作者: 閃客sun
來源: www.cnblogs.com/flashsun/p/9450066.html
dbaplus社群歡迎廣大技術人員投稿,投稿郵箱:[email protected]