加入新公司,怎樣快速熟悉業務和項目?

轉載自:https://www.toutiao.com/a6599078103778066947/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1539844728&app=news_article&utm_source=weixin&iid=46282795224&utm_medium=toutiao_android&group_id=6599078103778066947前端

不少新人進入一家新公司後,最頭疼的就是如何快速瞭解公司的業務和項目架構,或者說不要求快速,即使有足夠的時間,也很難在龐大的業務中整理出思緒。固然,若是你碰到一個特別熱心的老員工,事無鉅細地給你講,隨時在你身邊答疑解惑,那可能還好。java

但很惋惜,我沒有碰到這樣的人,在加入新公司後,帶個人人幾乎沒花時間給我講項目,也沒給我安排能夠熟悉項目的任務。android

就這樣的一個多月時間裏,我慢慢靠本身的力量熟悉了大概十個項目,並在過程當中總結了一些方法,藉此機會記錄一下,分享給你們。git

首先在這裏強調一點,個人策略不是快速瞭解一個項目的具體業務,由於這個不一樣項目也不同,沒法總結。個人策略是大致瞭解整個業務線上的全部項目,大概摸清楚每一個項目都是幹嗎的,它們之間的關係如何,以便之後不論具體負責哪一個項目都不至於找不到方向。shell

這樣等到須要負責具體到細節的業務時,雖然依然須要花時間,但相比總體一頭霧水地開始,仍是簡單許多的。數據庫

1、必要條件後端

咱們首先要想的是,有了哪些必要條件後,給你足夠的時間,你纔可以徹底瞭解整個項目?api

這裏說的必要條件不是「項目面對的客戶是誰」、「項目用的框架是什麼」這種,而是真真正正的必要條件,就比如用幾條數學公理能推出整個數學體系同樣。這裏我總結的真正的必要條件只有兩點:安全

  • 源碼位置(gitlab或svn);架構

  • 部署環境(dev/test/online);

所謂項目,其實就是一堆代碼放在了一堆機器上而已,因此這些就足夠了。

固然,爲了更加節約時間,最好還要有wiki、jenkins、頁面訪問路徑、數據庫地址。

我之因此說那兩個是必要條件,是想說其實項目本質上就是這麼簡單的一個事,你千萬不要想的太複雜。它的業務能夠無限複雜,但它的本質卻逃不出這些,你千萬不能夠糊塗。當你無從下手或者什麼都不清楚的時候,就主要把源碼和環境弄清楚吧,其它的都是附屬品。

2、從頁面到數據庫的線

有了上面的必要條件後,咱們就開始瞭解項目了。因爲不僅是一個項目,因此千萬不能深刻具體代碼,不然你就愈來愈煩直到放棄,也不會有好的效果。

對某個具體項目的瞭解,必定要創建在對總體瞭解的基礎上。這時咱們首先爲各個項目畫出一條線,並標明每個節點的信息,就像下面的樣子:

頁面訪問路徑——前端項目——後臺服務——數據庫地址

這裏的一個前端項目可能對應多個後臺服務,因此最終的圖應該差很少是這樣:

加入新公司,怎樣快速熟悉業務和項目?

這個整理的過程,主要是讓本身梳理清楚,一共有哪些項目,哪些是前端可視的,哪些是後臺提供服務的,而且大體瞭解前端項目分別調用了哪些後臺服務。經過後臺服務和數據庫的名稱,咱們能從本質上了解到這條業務線提供了什麼功能;從前端項目和頁面路徑,咱們能瞭解到咱們須要給用戶展現什麼。

注意,這個階段咱們只是見名知意,即便點開頁面,鏈接上數據庫看看,也千萬別花過多的時間,由於這個階段的重點就是僅僅知道這條業務線提的總體內容。

在此基礎之上,這個圖能夠不斷細化,好比項目部署的機器,咱們能夠標註在項目旁邊,或者保存在Xshell裏。此外全部非業務相關的,能查到的儘可能都記錄下來。這個真的爲之後找各類東西提供太多方便了。若是不在這一步這樣作,別看你如今節約了時間,但等到之後查找相關東西的時候,時間加起來將會是天文數字了。

這裏關於整理項目部署的機器還有個小插曲,跟你們分享一下。

因爲這部分的信息沒人會一個一個地告訴你,就算有也不可能說的特別全。因此我是藉助jenkins來整理的。項目部署都須要用到jenkins,只要查看jenkins配置的命令,就能夠把部署環境一一整理出來,這個我認爲是最全並且最新的。

不要和我說查wiki,若是公司wiki都寫的這麼全,我估計就沒這篇文章什麼事了。當時個人jenkins權限特別少,只能看一部分項目,並且還只能執行,不能看配置,帶個人人也是摳門,每次問他都給我開通所須要的項目的執行權限,多一點都不給。後來我也懶得問了,因爲jenkins機器你們均可以用root權限登錄,因此我進入jenkins的配置文件config.xml,給我本身添加了一個admin權限,重啓jenkins,再打開以後屏幕滿滿的項目都出來了,並且均可以查看和修改,暢通無阻。我就這樣經過一個個jenkins的配置,整理了部署的機器,也看了下啓動的邏輯。

3、瞭解項目間的關係

這部分若是有老員工願意和你說說,那最好仍是瞭解一下。若是沒有也不要緊,先跳過這段,之後慢慢了解也是能夠的。

4、整理數據庫表

咱們上面都是整理項目的大致框架,尚未涉及到具體的項目細節。這一部分,仍然不去涉及。

若是說站在整個業務的本質上看,業務無非就是一堆代碼運行在一堆機器上;那麼站在單個項目來看,一個項目無非就是對數據庫的增刪改查操做而已;或者從使用者的角度看,一個項目就是輸入一些參數獲得一些返回結果而已。

因此接下來咱們要作兩件事:一個是整理數據庫表,一個是整理Controller層的全部接口。

  • 找核心項目:這裏首先要選擇一個核心項目去看,衆多項目中必定有一個是核心項目,就先從這個開始看起。

  • 篩選核心數據表:若是數據庫的表比較少,那咱們拿工具導出來表結構,一個個看就好了,這個不難。但若是數據庫表特別多,咱們首先要將表名所有導出,篩選出那些核心的表。這裏導出表名、篩選表以及後面的分析表字段,不妨給本身作個工具,我在遇到一些很麻煩的或者感受之後還能夠通用的事情時,就會作成一個小工具,放在一個我給本身起名爲javamate的程序中,這些小工具逐漸積累起來你會發現從此有意想不到的方便。

  • 判斷哪些是核心表:不要着急,咱們首先排除掉一些沒用的。拿我在公司分析的系統來講,一共150多個表,其中有好多copy結尾的是備份,flow結尾的是流水,rel結尾的是中間關聯表,statistics結尾的是數據統計表,log結尾的是日誌表,config結尾的是配置表,等等。排除掉這些對核心業務理解無影響的表以後,所剩的也就20來張表,再根據它們的名字,能夠看出好多表是屬於一類的,好比order表就有各類order,按類別再分出來也就四五類,再分析起來就不難了。固然若是是更大的體系結構,那就要再不斷作拆解。

  • 找出表之間的關係:在具體分析這些核心表字段以前,還要作一件事就是找出表中間的關係。若是表b中有個字段,好比叫a.id,那麼b和a就是一對多的關係;若是兩個表有rel中間表,那兩者就是多對多的關係,起碼從邏輯上講是這樣的。這個分析過程我也是作了個小工具,經過程序來判斷的。

到此,你就對總體的數據庫結構有所瞭解了。根據表名也能對錶的大體內容有所瞭解,接下來就是針對具體的表,看裏面具體的字段和前人給出的備註,這個過程就沒有技巧了,要耐心,要慢慢熬。

5、整理Controller層接口

當對數據庫表作了以上的瞭解後,你基本上對這個系統能提供什麼服務瞭解得差很少了。這個時候不論你的代碼長什麼樣子,數據庫擺在那裏,能提供的服務差很少就已經出來了,對有經驗的人來說,代碼的業務邏輯也大體能猜到個八九分。

咱們梳理了大後方,那接下來就是把最前端和別人交互的部分搞清楚,這樣掐頭去尾,整個項目就解剖的差很少了。

這裏我也給本身作了個小工具,掃描出全部的controller層的接口,展現出方法名、路徑名、參數列表和返回值等,但惋惜沒能展現註釋,有大神有想法的話也歡迎幫我想一想。

和數據庫同樣,若是接口不多,那麼一個個看;若是特別多,仍是先找出比較核心的幾個方法研究。

這裏我用的是postman,把要研究的接口訪問保存起來,而且添加訪問成功和失敗的Example。我推薦本身開發的時候也把postman用起來,越詳細越好,postman不僅是能夠簡簡單單訪問你的接口,還能作批量測試,還能夠生成api文檔用於和前端交互。這樣你不但測試了本身的接口,還省的寫文檔了。並且postman還有個好處就是能夠給本身的接口mock一個服務,這樣即便你的接口掛了,或者接口根本就沒寫好,也可讓前端人員先訪問你的mock,徹底不影響前端邊測試邊開發,這纔是真正的先後端分離嘛。

6、從新理清項目間的關係

好了,這時候每一個項目你已經大體瞭解,最起碼調用的效果,數據庫所能提供的服務,你是清楚的。至此,就要從新整理下項目之間的關係了。

  • 根據以前的接口名稱,詳細瞭解下項目間的調用關係。理不清的部分去問老員工,這時候你帶着本身的瞭解問,他們也能給出更多的信息。

  • 看看每一個項目中用到的中間件,主要是mq服務,看看誰是生產者,誰是消費者,以此來了解關係。

  • 這時你應該已經開了好幾輪的週會了,接下來的週會你應該能聽懂部份內容。根據每一個人的描述和最新的幾組需求,逐漸摸清楚如今項目面臨的問題,以及哪一個項目是核心,哪一個項目是輔助,哪一個項目是以穩定安全爲主的。

到此爲止,你對整條業務線就有了大體的瞭解,接下來就能夠結合你具體負責的內容、領導安排你作的方向,去看具體的業務代碼了。

雖然以後的步驟依然須要你深刻其中,事無鉅細地瞭解具體內容,但此時,你經過前面的努力,已經能夠站在必定的高度看每個項目了,雖然你細節上仍是不瞭解,但這是徹底不一樣的。

在研究具體業務代碼的同時,不斷地跳出來看整條業務線的框架,修正以前因爲不瞭解具體業務而理解錯誤的架構。

久而久之,你必定會在某個項目中脫穎而出,讓你們認識到你的全局視野,這也是走出總是寫增刪改查代碼怪圈的一個途徑。慢慢會有人意識到,你對項目的理解總能站在全局的視野,不少須要跨項目去作的業務,也會天然而然想到你,慢慢地,你會接觸到更爲核心的東西,成爲架構師,或者去轉向產品,轉向管理。

這就是我總結的瞭解項目的過程,我工做年限很少,經驗上還不夠豐富,但願大佬們多多留言指點,提出問題,共同進步。

相關文章
相關標籤/搜索