寫業務代碼有成長機會嗎?關於這個問題,答案很是確定:必須有成長機會。對於大部分公司而言,可以寫底層代碼或者中間件代碼的人老是有限的,寫業務代碼會面臨更高的複雜度。前端
這裏分三個層次來看其中的成長機會。程序員
下面經過例子分別針對這 3 個層次進行講解。數據庫
這裏看一個例子,常見的代碼以下: segmentfault
這段代碼其實能夠寫成這樣: 架構
這裏舉一個煙囪型架構重構的例子。某團隊在早期發展階段對新來的每一個業務都會搭建一套系統,業內人士將這種見招拆招、垂直化發展的架構稱爲「煙囪型架構」。煙囪型架構並不是一無可取,在早期業務成敗未知的狀況下,不過分設計架構,能直接、有效地支持業務。工具
不過,隨着業務的發展,「煙囪」愈來愈多,對這些「煙囪」的後續維護成爲很大的問題,「成長」的煩惱如期而至。 學習
其中存在的問題以下測試
那麼,能不能將其中 80% 甚至 90% 的共性問題抽象出來呢?核心領域模型是否能夠穩定呢?spa
在既要支持不斷出現的各類業務,又要建設新平臺的糾結中權衡以後,該團隊首先啓動了平臺化項目,建設路徑是存量業務繼續使用煙囪架構,但新業務隨着新平臺一塊兒接入,而後逐步遷移存量業務,實現煙囪系統的下線。如圖所示,優惠券平臺對前端業務提供統一的能力輸出。 設計
總結下來,平臺化架構有以下好處。
架構不服務業務,那麼再高大上都是空話。技術不是炫技,要服務於商業。對於抽象共性的問題,業務平臺化要解決業務的共性問題,好比天貓、淘寶都有各種營銷活動,那就抽象出一個營銷平臺來管理營銷活動、營銷工具的整個生命週期,並提供給前端業務使用。
舉個例子,曾有一位作事很是努力、成長也比較快的小兄弟訴苦說,他以前在作網關程序,作得很細,除了完成了業務還保障了系統沒有 Bug,還使文檔沉澱、效率提高,外部機構聯調合做方好比銀行對其反饋也很好,但你們對其印象是善於合做,技術貌似通常。這位小兄弟在最近一年又作了業務平臺,以爲本身在分析設計、中間件技術的應用上已經進步很大,甚至對本身的成長也很滿意,但其餘人仍是認爲其技術貌似通常。這位小兄弟百思不得其解。
筆者的反饋以下。
再舉個例子,小郭在幾年前參與了一個接入類業務,當時已經有很多機構接入了這個業務,業務規模不大不小,產品經理換了幾茬,研發團隊也變動了三次。當你們日復一日地作業務接入、測試、發佈時,有人發現這個業務缺乏一個業務視圖。也就是說,這個業務有對系統資源的檢測、對接口調用的監控,可是沒有對業務運行狀況的監控,看不到地區粒度、子業務粒度的變化狀況等,甚至 BD 在簽定新業務時都不瞭解爲啥某地區已經沒有調用量了。小郭利用業餘時間開發了一個業務視圖工具,整個團隊立刻就感覺到他的過人之處了。有人講,大公司不是應該什麼都就緒嗎?實際狀況是,大公司也是經歷了業務的高速發展的,能夠這樣說,大部分公司並不缺乏作得更好、作得不同的機會!
因此,「寫業務代碼有成長機會嗎」這個句式還能夠改成「維護老系統如何晉升」「作商戶接入如何走向高端」和「項目這麼忙如何學習」,咱們須要進一步將本身的知識和經驗系統化,造成相關的方法體系。
在心態上,筆者提兩點建議:一是欣賞本身的成長,二是作個有心人。
感謝您的閱讀和關注。
《程序員的三門課》讀書筆記,做者:於君澤
主要是大前端技術以及程序員成長精進相關內容,文章首發於同名公衆號,若是你想第一時間接收最新文章,那麼能夠掃碼關注。若是對你有一點點幫助,能夠點喜歡點贊點收藏,還能夠小額打賞做者,以鼓勵做者寫出更多更好的文章。