由微服務聯想到如何保持職場競爭力

     近期由springboot掀起了一股微服務的熱潮,用過微服務的都知道,採用springcloud的架構,開發一個微服務時通常採用springboot+apollo或config+mybatisplus+代碼生成器 , 基本上簡單的業務邏輯直接就能一套生成了,而且由於統一配置中心可以節省大部分配置,充分實現了 敏捷式開發,與原來的SSM架構相比,是開發變得更加自動化,基本實現了開發只需要關注業務邏輯,無需關注其他更多的東西。所以在我們習慣了這一套開發模式後,如果沒有保持職場危機感,我們很容易陷入業務中而不可自拔,導致我們的職場競爭力成直線下降。接下來我會從幾個不同的角度談一下如何保持職場競爭力:

1. 公司

        站在公司的角度,大多數公司都是業務驅動,通常業務開發的代碼會很簡便,尤其是在習慣了開發流程之後,會有大量重複繁雜的工作,那在我們完成相關的業務代碼後可以考慮下有沒更好的實現方式。由於最近的996.icu很火,可能導致大家對公司的工作態度沒有那麼上心,抱着一種幹完收工的心態,事實上這種消極的心態對公司和員工都是不利的,員工的代碼質量不高,公司的業務發展也會停滯不前。理想的狀態是:公司的業務發展迅速,員工的代碼能力水漲船高,應該是相輔相成的一個狀態,而不是一個相互抵制狀態。有時候我們得失心太強了,太功利,總是希望自己付出立即就能得到結果,其實工作的時候我們可以耐心點,多給自己點時間成長,多思考一下是否有更好的實現方式,不要過於急功近利,抱着一個開放的心態去學習成長,這是保持職場競爭力的一個重要方式

2. 個人

        站在個人角度上,最有職場競爭力的當然是技術驅動。所以在平時我們完成業務開發後,需要保持自己的技術進步,無論是對技術的深度挖掘還是對技術廣度的擴展,都可以加深對技術的理解。在平時空餘時間,我們需要有更多的時間思考是否有更好的解決方案,這也是提升自己的一種方式。比如我當時在一家第三方支付公司中,主要工作是對接各個銀行的不同業務支付通道,在對接了幾個之後,我發現每個銀行基本都是相同的套路,新建一個通道類,實現對應的業務接口,採用http+json 或者tcp通信,然後是一些不同的MD5、BASE64、RSA雙向非對稱加密、DES等加密方式,最後傳輸對應的字段過去進行交易即可。所以在基於此的業務上我抽象出了一個代碼生成器:每當有一個新通道時,通過選擇對應的業務接口、通信方式、加密方式、傳輸字段生成通用的一套代碼,對比原來對接一個通道節省了60%的時間,使開發變得效率更高,同時也減少人爲操作帶來的bug。通過代碼生成器,我們可以想到能用代碼做的事情,儘量不用人爲處理,同時也能加深對代碼的理解。

       可以說80%以上的公司都沒用到分佈式以及分庫分表相關的操作,基本上都是在業務邏輯裏面來回打轉,如上文所說使用了springboot全家桶+代碼生成器後,基本上滿足簡單業務接口了,如果我們只是滿足於業務邏輯,做完之後就開始摸魚,那麼在多年以後我們依然是在原地踏步任何進步。所以在空餘時間我們可以查看一些框架的源碼實現,比如springboot如何實現對springmvc,mybatis等自動進行裝配的,mybatisplus是如何對mybatis進行二次封裝的(ps: 通過反射獲取對象屬性動態生成通用的crud SQL),或者學習一下分佈式相關的項目教程都是可以對自我進行提升的方式

      然後是一些軟技能的提升:交流溝通的問題,程序員大多習慣與代碼打交道,在表達溝通能力上可能會有所欠缺,表達能力需要個人平時的積累和鍛鍊,我們鍛鍊的途徑主要就是技術分享這一塊,多分享無論是對自己表達能力的提升,還是同事專業技能的成長都有好處。有過跨部門溝通經歷的同學都知道,大家很容易在某一個問題上爭執不下,不肯讓步,就是因爲我們都希望以自己表達的思想爲主,結果導致誰都不服,所以在跨部門溝通的問題上要善於傾聽對方表達的意思,不要固執己見,從而導致固步自封,適當的妥協也能達到雙方共贏的層面

總結:

       在這個習慣吃快餐的年代,我們很容易就會變得懶惰停滯不前,習慣了在業務上來回打轉,忽略了底層技術細節的積累,希望我們在業餘時間可以有更多的思考,在技術上保持前進,保證自己的職場競爭力,以此文章與諸君共勉

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章