要想成為一名優秀的大數據平臺開發工程師，只要做到深度與廣度并重，鉆研技術、理解產品、能搭架構、能解Bug，那就妥妥的了。優秀的人都是類似的，說起來就太過無聊了。所以，本文換一個角度，聊聊如何做到不那么優秀，要想成為一名糟糕的開發工程師都需要有哪些表現。

本文選自《大數據平臺基礎架構指南》一書，原文篇幅較長摘取時有部分刪改。

[[246281]]

我是小白我怕誰

要想成為一名糟糕的大數據平臺開發工程師，首先你得干上這行，怎么入門不重要，重要的是自我修養要從入門抓起。

大數據開發如何入門?在各種論壇或技術會議中，時不時地會有人問起這個問題。而提問者的問法往往也很類似：對大數據開發很感興趣，想學大數據，但不知道該怎么入門?應該學些什么呢?

對于這個問題，我也總能估計到提問者的預期答案。應該包括一串技能清單，以及回答問題者自身的成功實踐示范：先看什么書，再學什么課程，然后搭建一個什么系統。***列一個完整的學習計劃和清單，要是還有各種職位需求的市場調研和薪資待遇的統計分析那就更***了。

至于搞清楚自己到底喜歡什么，為什么喜歡，很重要嗎?讓專家來替自己做主，直接告訴自己該學什么，效率豈不是更高?

敏而好學，不恥下問

學什么的問題解決了，下面來解決怎么學的問題。

遇到問題前先思考一下，看一下文檔，讀點代碼，分析一下日志?不存在的。都什么年代了，社交為王。微信里加了這么多大數據群組干嗎用的?“討論”問題啊!“敏”而好學，快就一個字!

要是有人膽敢拿出“如何問一個好問題”這樣的垃圾文章出來敷衍這樣好學的同學，那就是傲驕。往往會被這位同學反駁：問一下不可以嗎?你懂還是不懂?懂就回答，不懂就不要胡說!古人云：不恥下問，你能有回答的機會就是你的榮幸!

那么，如果想在這個領域長期耕耘下去，這樣做靠不靠譜呢?據說大數據平臺相關開發工作，面對的問題往往是復雜的，需要從業人員具備良好的學習總結和推理分析能力。如果不具備主動學習和思考的習慣，聽說也就幾乎不可能成為這個領域的專家?

在這些同學看來，這種言論簡直就是妖言惑眾。事實勝于雄辯，明明有好多公司，有很多同學，在日常工作中就是這么做的。他們也搭過集群，復制粘貼過代碼，寫過ETL程序，遇上過“特別復雜”的難題，比如集群莫名其妙起不來了之類的，百度一下專家推薦的配置參數或者搜索一下出錯信息就搞定了，還經常寫點“我司數據平臺的踩坑經驗和實戰的分享”，你就說牛不牛吧!

什么?這種情況長久不了，這類工作遲早會被替代，尤其是在偏底層的基礎平臺開發工作環境中?那得多久的將來啊?至于AWS和阿里云平臺上的標準化服務，沒聽過，我們要有自主知識產權啊!

效率優先，中文至上

能百度就不谷歌;能找到不知道誰寫的搭建筆記，就堅決不讀官網的向導文章。要是還有手把手的教學視頻，那就更好了。

集群如何調優?問題如何解決?根據錯誤信息，搜索踩坑指南，別管花多少時間，在多么不起眼的博客也要搜出來。至于官網的問題FAQ或性能調優指南，抱歉，沒時間看。至于郵件列表和Jira，那是什么東西?

怎么，這么做不行嗎?有些同學可能回答，這也沒啥大不了，不是看不懂英文，但是還是更習慣看中文，如果不到山窮水盡，能用中文就用中文唄。

或許你總能給自己找到這么做的充分理由，但除非你想永遠玩別人早就玩剩下的東西，否則，還是應該盡可能接觸***手資訊。覺得英語水平差，看英文文檔代價很高嗎?實際上，篩選過時或錯誤信息的代價可能更高。

流行的就是***的

什么技術熱門就學什么，不管自己行不行，先看賺不賺錢。

這種現象不只在大數據領域存在，在各個技術領域都存在，從這幾年我所接觸的求職者的求職意愿上就能很明顯地看出來。

無論校招還是社招，無論是剛從別的方向轉行想做大數據，還是在大數據領域內已經有過一些簡單業務開發經驗的同學，幾乎90%以上的應聘者都會把自己將來的工作和實時計算掛上鉤，越是“初生牛犢”越是積極。可不，不玩Spark，不玩Flink，還怎么跟上時代，大家都說Hadoop已經被淘汰了!

其實蹭熱點本身問題不大，不過要想長期發展，關鍵是你本身也要具備相應的實力，大家都想做的事，你憑什么能比得過別人，就算現在沒問題，過幾年等該領域成熟了呢?與其研究哪里是熱點，不如想想自己適合做什么樣的工作，如何讓自己在技術的變革中持續成長。

我們的征途，是星辰大海

也有同學會說，我并不是跟風追熱點，只是當前的工作真的不適合我，我希望去做更有價值、更有挑戰的事。為什么現在的工作不合適呢? 比如：

• 業務太煩，瑣事太多，沒有時間學習。
• 干了很長時間，重復勞動，沒有成長的空間。
• 系統很成熟了，沒有什么可做的了。
• 做的事沒挑戰，發揮不出我的能力。
• 做的事太普通，覺得沒前途。
• 問題太多，團隊技術水平太差。

總之，就是我行，但是，這事不行、環境不行，所以我要換方向、我要換地方。

誠然，上述情況未必不客觀，很可能也是這些同學在工作過程中的真實感受。但我敢說，如果這就是全部原因，那么，有一多半問題的根源不在環境，而在我們自身。因為上述情況只是問題和現象，不是答案和原因。

• 瑣事太多，重復勞動太多?有沒有思考過如何化繁為簡，還是只會用體力勞動代替腦力勞動?
• 系統成熟，沒什么可做的?是系統真的***無瑕了，還是我們坐井觀天，眼界太低，不知道該如何改進?
• 做的事沒挑戰，做的事太普通?是事情本身太普通，還是做事的目標和方法太普通?
• 問題太多?是同事能力太差，還是自己只會頭痛醫頭，解決問題不徹底，又或者是沒有能力推進復雜問題的解決?

當然，每個人都希望在一個***的環境中工作，這并沒有錯，但如果你只是單純地回避問題，而未曾解決過這些問題，那么在新的環境中，你早晚還是會遇上同樣的問題。

書中自有顏如玉，熱衷閱讀代碼

有些同學，特別是經常和開源相關組件打交道的同學，會特別喜歡閱讀代碼。

閱讀代碼，當然沒錯，說實話，愛讀代碼的同學現在也不好找了。但是，過猶不及，畢竟閱讀和熟悉代碼只是手段，而非最終目的。遺憾的是，有時候，很多同學往往并沒有認識到這一點。

這些同學很可能慣性地認為，只有依靠完全徹底地理解代碼，才能得到***手資料，才能更好地評估實施方案。

而事實上往往事與愿違，一方面，你可能迷失在一些無關痛癢的局部細節上;另一方面，你可能忽視了真正需要盡早找出答案的問題。

實際上，這也是一種用戰術上的勤快來掩蓋戰略上的懶惰的行為表現。因為閱讀代碼可能是程序員最習慣做的事。但是，采用其他可能的方式去評估或熟悉一個未知的系統呢?

比如詳細閱讀官方文檔，進行功能驗證和Demo測試，對類似系統進行橫向比較，收集他人踩坑經驗，尋找問題的其他可能解決途徑等，這些工作往往有可能更加快速全面地幫你了解一個系統，并做出合理的方案設計。但是這么做會涉及持續的思考、分析、判斷和嘗試的過程，所以有時候很多同學往往不愿意在這上面多費力氣。

謎之問題的謎之解決方式

相比閱讀代碼的執著，很多同學在分析問題時的表現卻往往與之相反。

分布式環境下的問題往往錯綜復雜，如果一個問題不是明顯的確定性邏輯錯誤，而是跑得慢、性能差、莫名其妙地隨機崩潰、超時等，不少同學很容易就快速陷入迷茫中。而為了將自己從迷茫中掙脫出來，往往會在問題排查過程中，輕易地將某些故障的現象歸結為故障的原因，進而以治標不治本的方式來解決問題。

做得好一點的代碼流派的同學則可能在排查問題過程中，發現一個Error或Warning日志，還會去閱讀相關的代碼，***花幾天時間閱讀完代碼，可能分析出了什么流程會打印出這個Error日志，但卻不知道或者解釋不了為什么當時程序會走到這個流程，同樣也就排查不下去了。

上述情況，通常還是方法論問題，不知道如何把握問題的重點，在問題自身信息尚未收集清楚的時候，就過早地聚焦在某個收益未知的現象上。而對于進一步的動作，比如：

• 質疑問題，考證現象，現有的結論是否站得住腳，是否還有疑點。
• 能否再多方面收集一些信息，或者換一個角度，嘗試用別的方式分析問題。
• 能否想辦法復現問題，或者學習新的技能解鎖進一步分析問題的能力。
• 能否改進日志，爭取下一次問題出現時能收集到更多信息。
• 在自以為修復問題后，能否針對性地進行后續的監控分析，看看是否真的解決了問題。
• 在類似這些工作方面，往往就沒有表現出應有的執著了。

勤奮好學，但是回頭即忘

作為一個有夢想的工程師，你一定會去關注新技術。

如果方法得當，在短期內依靠深入閱讀文檔、翻閱核心代碼等手段，你往往可以快速地在幾天內對一個系統形成基本的認知。

只可惜，大數據領域的技術日新月異，加上很多系統相對復雜的架構特點，決定了這些新技術往往信息量不小，如果你沒有真正深入地實踐過，通常很難形成有效的長期知識記憶。可能再過一個月，你剛掌握的內容就都忘得一干二凈了。

花費的精力就要產生價值，做好留存工作，在一個需要長期積累的領域，很多時候可能比拉新更加重要，將來的激活成本也會低很多。

總結

[[246282]]

反面視角談完了，再從正面雞湯的角度總結一下吧：

• 有“錢途”的方向，未必適合你，除非你具備戰勝80%以上的跟風者的能力。
• “快速”學習的結果通常是欲速則不達，請學會思考，請閱讀***手資料。
• 閱讀代碼很重要，但比閱讀代碼更重要的是閱讀問題。
• 知識面決定了你的廣度，但信息不等于知識面，人云亦云的概念一錢不值。
• 在抱怨工作之前，先審視自身問題，畢竟改變自己更加容易，也更普遍有效。

***再補充一句在食品安全反偽科學中常說的一句話：“脫離劑量談毒性，都是耍流氓”。上述所有問題，并無絕對的對錯，重要的是對程度的把握，你是否認清了自己的目標，你所做的事情與你想要的結果是否能夠匹配。