我是小白我怕誰

要想成為一名糟糕的開發工程師，怎麼入門不重要，重要的是自我修養要從入門抓起。

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

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

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

敏而好學，不恥下問

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

遇到問題前先思考一下，看一下文件，讀點程式碼，分析一下日誌？不存在的。都什麼年代了，社交為王。微信里加了這麼多技術交流群組幹嗎用的？“討論”問題啊！“敏”而好學，快就一個字！

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

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

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

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

效率優先，中文至上

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

叢集如何調優？問題如何解決？根據錯誤資訊，搜尋踩坑指南，別管花多少時間，在多麼不起眼的部落格也要搜出來。至於官網的問題FAQ或效能調優指南，抱歉，沒時間看。至於郵件列表和Jira，那是什麼東西？

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

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

流行的就是最好的

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

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

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

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

我們的征途，是星辰大海

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

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

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

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

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

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

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

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

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

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

而事實上往往事與願違，一方面，你可能迷失在一些無關痛癢的區域性細節上；另一方面，你可能忽視了真正需要儘早找出答案的問題。

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

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

謎之問題的謎之解決方式

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

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

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

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

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

在類似這些工作方面，往往就沒有表現出應有的執著了。

勤奮好學，但是回頭即忘

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

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

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

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

總結

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

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

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