成長之悟

　　最近或許有夥伴發現，寫技術實現及細節的變少了，更可能是經歷以及思想、規範。莫非是道則道，很是道，你道我也道？然，並非：）。

　　當入行四五年時，我的經歷中，從14年開始實習工做到15年轉正，各電信項目現場跑，開發、測試、產品部署及支持運維。16年銀行實時系統開發、測試、運維、部署，最後推動了MapReduce與spark引擎的變動。再到17年來阿里至今，從0到1 負責系統及將來發展的設計、開發、測試及運維 以及 開始推廣運營。每個項目都帶來巨大的成長，有時候感受這些年對本身的確挺狠的，心疼的抱住不胖不瘦的本身，可是帶來的成長也是巨大的，這裏的成長並不僅是技術或架構能力的成長。更多的是從一個小白膽怯到一個相信本身，可以把控項目、團隊合做、把控風險、把控情緒的過程。這個過程很痛苦，很鍛鍊人，可是卻能讓本身更加的無懼將來。 就像個人博客中的個性簽名，這個世界上，沒有平白無故的恨，也沒有平白無故的愛，更沒有平白無故的橫空出世。這仍然是一個相信汗水和淚水的世界，全部的'被看到',全部的'能發光'，都不過是在灰塵撲撲的日子裏，不動聲色，盡心盡力的結果。那麼在這裏，分享一些本身的想法給你們：

　　一、改變 

            簡短的兩個字，其實並不那麼容易作到。咱們都來自不一樣的家庭環境、不一樣的教育背景、不一樣的經歷，會擁有着不一樣的價值觀、不一樣的思想、不一樣的理想，爲着馬斯洛需求層次中的某一層而努力。　　

　        在每一個通宵的夜晚，你是否也有過對人生的懷疑？是否有過，對將來的迷茫？又是否有過在種種迷茫、懷疑之下的堅持？又是否在堅持以後，可以帶着前一次的自信，鼓起勇氣，再次去挑戰新的懷疑、新的迷茫以及困惑。舉一個我的經歷，在第一家公司時，更多的是產品研發部署實施爲主。也許是年少輕狂，畢業不久爲了女朋友裸辭，從北京到上海，新公司所有都是大數據技術，與曾經掌握的技能並不match。天天極爲痛苦，由於你再也不是應屆畢業生，社招上來就要幹活兒，對本身充斥着大量的懷疑，直到可以owner並與夥伴們承擔整個數倉的改造--spark、hbase、storm、kafka、redis大數據各技術棧聯合研究運用以及銀行各事業部的數據服務輸出。然而，到達必定時期後，以爲很舒服，擁有admin權限的你，擁有設計話語權的你，或許已經成爲你的瓶頸。心裏告訴我，要迎接挑戰，要跳出溫馨區，因而選擇跳槽，簡歷投遞時，點了阿里巴巴。社招通過阿里集團兩個事業部的加起來七輪面試經過後同時錄取，選擇螞蟻金服。（新人啓示，不要以爲痛苦，以爲委屈，以爲壓抑而放棄，每爬出來一個坑你就會看到更清晰的將來。任何的不舒服，不要直接認爲本身不適合。換個態度去想，把它變舒服了，再去考慮你是否是更適合其餘的。）

　　

    二、先成爲專家

　　   咱們縱觀軟件行業，以個人認知來講，web技術，前端與後端開發，若是細分後端開發又分爲客戶端開發與服務端開發。 大數據技術，流處理（storm、flink、spark streaming....）、批處理(hadoop、spark batch....)、存儲技術(mysql、oracle、hbase、分佈式文件存儲hdfs....)、消息中間件(floom、kafka....)。網絡技術（socket、http、bio、nio、netty...），在各類技術應用開發的同時，也牽扯到各類數據結構、各類設計思想、數據字典設計、數據建模、數據架構等等等等。這裏就牽扯到定位，就是將來你想要成爲何樣的人。我記得曾經剛入行時，有一位微軟的大牛曾經跟我說，不要什麼都學，先成爲專家，再成爲百家。由於成爲專家的歷程中，必然會接觸各類思想、理念，爲舉一反三打好基礎。那麼不管系統開發也好、大數據開發也好、大數據技術也好、區塊鏈、人工智能等等，專精於一個領域，必能小有所成。但下來，要說的是，技術也只是知識體系中的某一項。

 

　 三、謙虛與合做

        咱們搞技術的有一點，會很是崇拜技術牛逼的那我的，臥槽，你這都會，臥槽，這麼牛逼，抱着大腿一塊兒成長。但你們有沒有仔細觀察，大神的作事方法，大神的思惟模式，同時會發現，技術大神通常都很是的謙虛，任由咱們隨意提出建議。而初出茅廬時，咱們總擔憂身邊的人以爲本身技術能力不行，擔憂人家笑話你。從而愈來愈不敢正視本身，推卸責任或是不敢認可是本身的問題，長此以往，咱們的成長便會受限。 這裏想說明一個觀點即是，任何人說出的任何意見或觀點，都必定有必定的理由在裏面。不要一開始就反駁，或者一開始就否認，先思考是不是本身欠缺的，是的話，歸入本身的思路體系，不是的話，咱們再就事論事的討論。你的成長，與他人的見解無關。長此以往，你也會擁有謙虛的態度，也會擁有大神的思惟模式。認可錯誤，這並非懦弱，也不在於誰對誰錯，而在於朝着同一目標前進。

 

    四、消除焦慮感

　　  行業有句話，35歲不轉管理就會被替代。其實我一直有個疑問，35歲時，我相信軟件工程師們都將成爲某個領域或是某個業務線的架構師，那麼架構師的定義是什麼？系統架構師是一個既須要掌控總體又須要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。一個架構師得須要足夠的想像力,能把各類目標需求進行不一樣維度的擴展，爲目標客戶提供更爲全面的需求清單（來自百度百科） 。我相信，一個架構師會具備管理的特質，也會具備很強的合做意識、風險意識、架構思想及處事不驚的態度。前十幾年豐富的開發、設計、架構能力，可以遊刃有餘的把控任何風險。同時由於看透技術本質，對於新興背景下產出的技術也會舉一反三。它就是咱們眼中的大神。一個優秀的架構師，對於不管需求、設計、開發、測試、運維、項目風險、溝通合做、業務背景的理解絲絕不會亞於某一項專項的業務人員（否則作出來的是客戶不要的？），架構師的價值不亞於任何管理者。

 

    五、體系總結 

         這兩年在阿里取經，有一個很是有用的方法，就是將本身學到的，實踐到的，領悟到的畫成知識圖譜，時常溫故。記得早年最笨的方法，就把一整本書先硬啃下來，工做實踐後，再去啃一遍，直到融會貫通。後來當體系創建，在看相關書籍時，基本一遍看下來再也不那麼吃力。這時候千萬不要覺得本身會了，依舊開始第二遍細讀，第三遍總結與知識圖譜。可是軟件工程的特性，必須實踐後纔會真正的領悟，那麼看了後，只是作了簡單的習題方法會不會沒用？ 踏實下來，當你要用到的時候，你會發現，原來沒那麼難。

 

　六、開放思惟

         與此同時，咱們容易被技術思惟禁錮，你們都以爲作技術是有瓶頸的，那麼有沒有仔細思考過，到底瓶頸是在哪裏？我的感受，技術角度是創造、想象 與 推進。如今對於工程師的要求愈來愈高了，已經不像傳統IT，作好一起就夠了，更多時候咱們須要和客戶打交道 和 業務打交道 和 需求 產品 ，甚至有時候本身都會上去設計產品。這個思惟方式的跳躍是很痛苦的，由於越是某項技術專家，越是沒法理解業務是幹嗎的，畢竟人的精力是有限的，註定會是某項技術的光輝支柱。可是若是不是對某項技術癡迷，想要成爲統觀全局的架構師，就須要不斷地擴展，對於技術而言，也許技術專家是5分，那麼你能達到3分。對於業務而言，可以洞察市場的動態。但同時還在於我的的視野、想象、背景、情商、修養、與格局，從而推進事物的發展。