it培訓是學java好還是大數據好?

得之你命


前言:

我先來介紹下個人看法

先介紹一下我的新同事,公司好多同事都這麼叫他James,有10年開發經驗的架構師,之前在人人網待過,之後我們也聊了很多。

在聊天過程中,我們也聊到了他為什麼離開人人網,也聊到了他在成為架構師的道路上的辛酸歷程,聊過後,才發現,離開人人網的原因和他的架構師之路和我的很是相似。都是經歷不知多少個日夜磨礪出來的辛酸歷程。現在回想過去,在看現在的自己,感覺之前的辛酸都是值得的。

好了,我在這裡就不跟大家扯這麼多了,今天的這篇文章,主要是我們兩在聊天討論的過程中,產生了很多在成為架構師的過程中的一些共鳴點,既然我們所經歷的點有共鳴,那麼我相信跟大家的也相差不大,所以,這篇文章僅供大家參考學習以及在成為架構師的道路上應該掌握的知識點和經驗。相信你在看完這篇文章後,你有一個明確的目標以及一個通往架構師路上正確的方向。

困擾架構師日常問題

架構師應不應該寫代碼

為什麼別人的系統總是那麼爛

成為架構師最困難的門檻是什麼?

如何更高效的學習?

面對目前流行的技術不知如何下手?

一家公司待久了,過得很安逸,但跳槽時面試碰壁?

覺得現在的技術基礎感覺到很紮實,但就是自己的技術提升不上?

覺得自己很牛B,一般需求都能搞定,但是所學的知識點沒有系統化,很難在技術領域繼續突破?

現在覺得自己技術還可以,但就是薪資漲不上去?

以上這幾點,做為開發人員的你們,有遇到過麼?有為自己想過麼?有細心仔細的去解決過這些問題麼?有深刻的想過麼?雖然這幾個問題很簡單,但對於我們在開發路上,是有非常重要的幫助的。

1:架構師應不應該寫代碼

合格的程序員對於明確分配的任務會完成的很好,但是大部分情況下“架構”這個詞意味著架構師並不會涉及太多細節,架構圖和代碼實現之間總還是有些距離,你無法保證所有人都會正確的理解你的設計,或者是程序員寫代碼時遇到障礙時會立刻想出足夠優雅的解決方案。

在我看來,寫代碼的架構師更像是在做後勤保障的工作:在代碼中第一時間發現可能存在的問題,向其他人提出警告,或是給予其他人改進的意見,必要的時候或是給其他人演示一下正確的姿勢。

大部分情況下我作為架構師並不需要攬下“核心模塊”開發這種工作,畢竟我能調配的時間太零散了,效率難以保證,很多人在專注的情況下比我做的好很多,我只需要保持大局觀需要適度參與就可以了。

總的來說,架構師和程序員在某些方面上有點像產品經理和用戶的關係,大部分程序員並不會主動告訴你他們想要什麼、哪裡需要優化,甚至自己也不知道這些。想要做出好的產品,捷徑之一就是跟用戶做同樣的事情。

2:為什麼別人的系統總是那麼爛

很多程序員解決問題的能力很強,說要解決一個什麼問題,下午就能寫出幾百行代碼把功能實現了。但是做出來的東西有種少考慮了什麼東西的感覺。大部分程序都能實現功能,但是如果把“時間”這個也作為一個考慮的維度的話,就會意識到一個合格的項目需要考慮更多的東西:更通用的使用方式、易於理解的文檔、簡單而易於擴展的設計,等等。

很多公司應該都會有一些遺留系統,它們龐大、笨重、難用、幾乎無法維護,所有人都在抱怨這些系統,並且每天都在想方設法換掉那些遺留系統。但是一段時間過去之後,又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了。

3:成為架構師最困難的門檻是什麼?

很多人自稱架構師的人跟你講一個架構時簡直滔滔不絕,各種技術名詞像是說相聲一樣從他嘴裡說出來,三句話不離高併發大數據,但是稍微追問一下,就會發現很多基本概念的缺失,例如自稱精通高併發的人說不清楚他所謂的高併發系統的瓶頸在哪裡,自稱精通架構設計的人說不明白他的系統怎麼保證高可用,自稱超大數據量的系統實際上只有不到100萬條數據,等等。

架構師雖然聽起來很高大上,但本質上仍然是工程師,不是科學家,也不是忽悠人的江湖騙子。學習再多,也需要實踐落地。設計架構方案更多的是在做一些抽象和權衡:把複雜的需求抽象成簡單的模型,從功能、性能、可用性、研發成本等等方面規劃如何構建一個系統,這些內容需要更多的實踐練習。

4:如何更高效的學習?

大多數人每天能留給自己學習的時間有限,這個階段如何提升學習效率就成了要解決的重點。

說說自己提升學習效率的心得,其實非常簡單:體系化的學習。

在重複了幾次痛苦的學習-梳理過程後,再去看一些獨立的文章或者資料往往會事半功倍,因為能在體系內找到相對應的知識,甚至有時候一本書裡一頁只需要看一句話,點破那層窗戶紙,就可以掌握新的知識。

跟很多人一樣,剛畢業時我覺得作為程序員,只要努力,加上少許天賦便可以獲得一些成績。

工作一段時間後,對自己和其他人的認識也越來越清晰,逐漸的發現程序員之間的差距或許比人和猴子之間的差距還大,接受這個事實這讓我鬱悶了很久。

再過一段時間,發現自己已經能夠客觀的評價自己的能力,也意識到了距離並不是那麼重要,只要想辦法跑的更快,就足夠了。

5:面對目前流行的技術不知如何下手?

第一,根據自己目前工作中所用到的技術,有目的性的學習;

第二,可以根據各大互聯網公司的招聘要求,有選擇性地進行規劃學習;

第三,可以參照文章尾部Java架構師所具備知識點,上面有從源碼到分佈式到微服務到併發等,是十多年的一群有經驗的老師整理出來的。

6:一家公司待久了,過得很安逸,但跳槽時面試碰壁?

很多程序員有這樣的情況,因為一直處於自己的舒適區,每天寫的是自己熟悉的業務代碼,更多的做的是crud的工作,技術上沒有挑戰性,覺得生活也還可以。但是一旦跳出這個舒適區,就會很難適應,不知所措,因為外面新的技術太多,自己完全跟不上技術的步伐,這時候需要梳理一下自己目前所欠缺的點,有針對性地進行提高。

7:覺得現在的技術基礎感覺到很紮實,但就是自己的技術提升不上?

這種技術紮實更多的是基礎,比如javase,javaee等,並不能適應一線互聯網公司的技術體系,比如分佈式,微服務這塊。技術提升不上是因為自己沒有接觸過相關的項目,以前那種基礎知識網上還一大篇,但是越往上走資料越少,好的資料就越少,而且越往上如果沒有引路人更加舉步維艱。

8:覺得自己很牛B,一般需求都能搞定,但是所學的知識點沒有系統化,很難在技術領域繼續突破?

這裡的一般需求,更多的應該是在單機環境之下的crud操作,項目沒有太多難度,頂多是業務上的分析複雜一些,技術用到了一些主流的技術,比如dubbo,也僅僅停留在api的使用層面,不瞭解其原理,而且與dubbo相關的其他技術分支並沒有很好的拓展,所以感覺很難突破。

9:現在覺得自己技術還可以,但就是薪資漲不上去?

需要弄清楚薪資由什麼決定,是由你的價值決定,而你的價值取決於你的技術能力,如果你的技術能力一直停留在crud的層面,肯定會上不去,你需要做的是突破技術瓶頸。(我相信這一點,是大多數開發人員會首先考慮到的問題)。

經過以上的幾個問題的總結,你們有一點點理解了麼?有什麼感觸沒?沒有?那麼你們繼續往下看。

程序員應有的幾個階段

第一階段----三年

我認為三年對於程序員來說是第一個門檻,這個階段將會淘汰掉一批不適合寫代碼的人。這一階段,我們走出校園,邁入社會,成為一名程序員,正式從書本上的內容邁向真正的企業級開發。我們知道如何團隊協作、如何使用項目管理工具、項目版本如何控制、我們寫的代碼如何測試如何在線上運行等等,積累了一定的開發經驗,也對代碼有了一定深入的認識,是一個比較純粹的Coder的階段。

第二階段----五年

五年又是區分程序員的第二個門檻。有些人在三年裡,除了完成工作,在空餘時間基本不會研究別的東西,這些人永遠就是個Coder,年紀大一些勢必被更年輕的人給頂替;有些人在三年裡,除了寫代碼之外,還熱衷於研究各種技術實現細節、看了N多好書、寫一些博客、在Github上分享技術,這些人在五年後必然具備在技術上獨當一面的能力並且清楚自己未來的發展方向,從一個Coder逐步走向系統分析師或是架構師,成為項目組中不可或缺的人物。

第三階段----十年

十年又是另一個門檻了,轉行或是繼續做一名程序員就在這個節點上。如果在前幾年就抱定不轉行的思路並且為之努力的話,那麼在十年的這個節點上,有些人必然成長為一名對行業有著深入認識、對技術有著深入認識、能從零開始對一個產品進行分析的程序員,這樣的人在公司基本擔任的都是CTO、技術專家、首席架構師等最關鍵的職位,這對於自己絕對是一件榮耀的事,當然老闆在經濟上也絕不會虧待你。

我認為,隨著你工作年限的增長、對生活對生命認識的深入,應當不斷思考三個問題:

我到底適不適合當一名程序員?

我到底應不應該一輩子以程序員為職業?

我對編程到底持有的是一種什麼樣的態度,是夠用就好呢還是不斷研究?

最終,明確自己的職業規劃,對自己的規劃負責併為之努力。

架構師所具備的知識點

一:常見模式與工具

學習Java技術體系,設計模式,流行的框架與組件是必不可少的:

常見的設計模式,編碼必備

Spring5,做應用必不可少的最新框架

MyBatis,玩數據庫必不可少的組件

二:工程化與工具

工欲善其事必先利其器,不管是小白,還是資深開發,玩Java技術體系,選擇好的工具,提升開發效率和團隊協作效率,是必不可少的:

Maven,項目管理

Jenkins,持續集成

Sonar,代碼質量管理

Git,版本管理

三:分佈式架構

高併發,高可用,海量數據,沒有分佈式的架構知識肯定是玩不轉的:

分佈式架構原理

分佈式架構策略

分佈式中間件

分佈式架構實戰

四:微服務架構

業務越來越複雜,服務分層,微服務架構是架構升級的必由之路,Java技術體系,和微服務相關的技術有哪些呢?

微服務框架

Spring Cloud

Docker與虛擬化

微服務架構

五:性能優化

任何脫離細節的ppt架構師都是耍流氓,向上能運籌帷幄,向下能解決一線性能問題,Java技術體系,需要了解:

性能指標體系

JVM調優

Web調優

DB調優

六:底層知識

從架構設計,到應用層調優,再深入瞭解底層原理,紮實的Java基本功才能讓自己變為掃地神僧:

併發模式

線程模型

高性能NIO框架


互聯網Java架構


現在比較火的大數據成為了眾多培訓機構的新的課程和賣點,那麼對於大專學歷零基礎的同學來說是否真的能夠去學呢?


首先要明確知道,大數據要比JAVA複雜得多!JAVA只是一種基礎編程語言。而大數據(big data )行業術語叫“巨量數據集合”!是完全不同的!


現在都說大數據很好,沒錯是很好,但是目前市場上做大數據主要是對於ZF或其他大企業的,而且學歷要求更高!


外,大數據並不是短期所能學會的。所以,建議非計算機相關專業,大專學歷的同學還是從JAVA學起。


希望我的回答對你有幫助。


Sinco西科軟件


如果是零基礎的話,建議還是一步一個腳印,先學習java,有了java基礎然後搞大數據。

首先大數據同樣是需要編程基礎的,hadoop,spark這些,你可以用java也可以用python腳本,還可以用scala。

其次,培訓機構的大數據不一定和企業契合,小公司都沒有數據給你搞。


業餘架構師


學起來容易,工作難。培訓班只講基礎語法,不講數據結構。框架只是介紹而已,沒有實質的東西。工作起來自己要去學,沒有計算機基礎的慎重啊。選擇大數據吧,java學習主要就是java語法+(spring框架+mybatic)框架+數據庫+後期工作中學習各種框架與其他知識。大數據應該也是 java語法+大數據中主流框架+數據庫+後期工作中學習各種框架與其他知識。培訓班中框架基本學不到什麼東西。對比看學大數據不虧,畢竟火嗎😊


雲驟小優美


看你個人基礎,如果是0基礎的話建議從JAVA開始,雖然大數據比較好,但是從知識結構、用人需求等等都更適合有基礎的學生,這類建議計算機專業、物理等相關專業學生學習。

如果是編程0基礎還是建議選擇JAVA,近年來JAVA一直需求比較多,薪資也不錯,選擇JAVA還是不錯的。

兩個相比較而言,JAVA更基礎,更適合新手學習。


分享到:


相關文章: