【秒懂Java】【第1章_初識Java】04_學習資料
為了學到更多的新知識，我們經常會去網上搜索各種學習資料。或者，在學習、工作過程中遇到了解決不了的問題，我們也會去網上搜索答案（比如百度、Google一下）。這篇文章，主要想跟大家聊聊關於學習資料的選擇。
建議
山寨
在日常生活中，有時稍有不慎，我們可能會買到一些讓人哭笑不得的山寨商品，比如
- 藍月殼（正品：藍月亮）
- 娃啥啥（正品：娃哈哈）
- adidogs（正品：adidas）
- 六日兔（正品：大白兔）
謠言
有時也會在網上看到各種謠言、假新聞，比如在新冠疫情期間，就出現了很多謠言，這些造謠者還真是唯恐天不亂呀，我選了幾則腦洞比較大的給大家「欣賞」一下。
所以，不管是購物，還是看新聞，官方渠道才是最靠譜的。
學習資料
我們在網上找學習資料時也是如此，肯定是優先選擇官方資料最靠譜，不然也可能會遇到「山寨」的學習資料，最後導致自己吸收了錯誤的知識。我們要學習的很多軟體開發技術，都源自西方國家（比如美國），因此很多官方資料都是全英文的，有時官方也會提供中文翻譯版，或者會有一些熱心的網友進行翻譯。關於Java學習資料的選擇，我給大家的核心建議是：不要完全相信任何非官方的技術資料！！！。
非官方資料
網上的很多非官方資料都有以下特點：
- 作者往往都是只按照自己的經驗在寫文章，但是這些經驗就是對的么？不一定。很多知識點都是粗糙驗證一下就得出結論，並沒有考慮全面和嚴謹，也沒有參考官方資料
- 文章的抄襲現象也比較嚴重，看到寫得有點道理的，就把它給抄了。你抄我的，我抄你的，只要有一個人的文章寫錯了，其他一大片人寫的文章都是錯的
推薦
Java的官方是Oracle公司，這裡給大家推薦一個Oracle官方的Java SE學習資料：The Java Tutorial（全英文），覺得看英文費勁的話，可以用工具翻譯一下。
錯誤資料
為了讓大家充分認識到官方資料的重要性。下面給大家列舉幾則不同領域的錯誤資料。
- 我並不認識作者，對作者也並無偏見，只是針對文章內容進行討論
- 如果你還沒有學過相關的專業知識，看不懂文章的內容是正常的，也不需要你看懂，你只需要知道這篇文章大概哪裡有錯就行
數據結構之紅黑樹
這篇文章的標題是《史上最清晰的紅黑樹講解（下）》。文章中的這幅圖畫得有問題，因為它根本就不是一顆紅黑樹，圖一旦錯了，後面的所有操作都是沒有意義的。
下圖是我在文章底下發表的個人淺見。
下圖是其他網友的見解。有人表示質疑。也有人沒看出有啥問題，並表示很贊。
C\C++的sizeof
這篇文章的標題是《C語言中簡單的sizeof（）函數》。不用看文章內容，因為標題就已經錯了。在C\C++中，sizeof並不是函數，它是一個運算符，函數和運算符是有本質區別的。但凡作者懂一點點彙編語言的話，都可以很容易通過彙編語言去證明sizeof並不是一個函數。
CSS選擇器[att|=val]
w3school這個網站估計很多學習前端開發的人都知道，裡面有大量前端開發的資料。但是，一個網站很知名，並不代表它的內容完全正確，畢竟它並不是官方。所以，我並不會完全相信它裡面的內容，也基本不會去這個網站查詢資料。這裡有一篇w3school關於CSS選擇器的文章，關於屬性選擇器[att|=val]的描述，極其不嚴謹：
選擇att屬性值以”val”開頭的所有元素
Represents an element with the att attribute, its value either being exactly “val” or beginning with “val” immediately followed by “-” (U+002D).
簡單翻譯一下，官方的大概意思如下：
選擇att屬性值剛好等於”val”或者以”val”開頭並且後面緊跟著一個減號（-）
如果你還不能感受到w3school和w3c官方描述的差異之大，我舉一個實例。比如有以下4個元素
<div id="mj">div1</div>
<div id="mj-xmg">div2</div>
<div id="mj_xmg">div3</div>
<div id="mjxmg">div4</div>
假設我使用屬性選擇器[id=mj]
- 按照w3school的描述，會選擇div1、div2、div3、div4四個元素
- 按照w3c官方的描述，只會選擇div1、div2兩個元素，div3、div4不符合要求
能感受兩者描述的千差萬別了吧？它們是完全不相同的兩個意思！
Java中class的JDK版本
這篇文章的標題是《如何查看class文件的jdk版本》，於2015年7月30日發表。
上圖中有3處低級錯誤，我都用紅線畫出來了。
- 8個位元組CA FE BA BE，正確說法應該是：4個位元組CA FE BA BE
- 4個位元組00 00，正確說法應該是：2個位元組00 00
- 4個位元組00 33，正確說法應該是：2個位元組00 33
學過電腦的同學應該都知道這屬於電腦常識，所以這是非常非常非常低級的錯誤。到了2019年，還是有別的作者轉載了這篇文章，標題也是《如何查看class文件的jdk版本》，內容也是一模一樣的，沒做任何變動。4年過去了，依然還是很多人不知道這篇文章是錯的。
我覺得大家多寫技術部落格、熱愛分享是件很好的事情。但是如果大家在寫文章的時候，能夠多參考官方資料、多加驗證後再發表出來，那麼我們技術圈的文章品質就會越來越高，作者自身的技術水平也將真正變得越來越好。
另外，如果你經常寫優質的技術部落格，當你寫到一定程度時，自然而然就會有出版社的編輯找你合作寫書，機會都是留給有準備的人。當然，寫書並不是一件容易的事，有很多嚴格的要求。
書中的錯誤
聽我說完前面的幾個錯誤示範，你可能會想：那我選擇看技術書籍應該會好很多吧？畢竟書本應該是比較嚴謹的吧？我想說的是：你想多了！首先，很多出版社是不清楚圖書內容對錯和含金量的；其次，圖書的內容是由圖書作者編寫的，跟他在網上寫技術文章並無太大區別，就是格式不一樣，圖書有一套嚴格的格式要求。所以，不管是網上的技術文章，還是你平時看的某些技術書籍，都可能是有錯誤的。比如這本翻譯的書籍《CSS權威指南》。
書中錯誤的地方我已經用紅線框住。
來看一下W3C官方的說法：
A double bar (||) separates two or more options: one or more of them must occur, in any order.
簡單翻譯一下，官方的大概意思如下：
它們至少出現1個，而且是任意順序
而《CSS權威指南》中說的是必須以先X後Y的順序出現，跟官方的說法完全不相符。
官方文檔的錯誤
看了這麼多的錯誤示範，你可能又會想：那以後優先選擇官方文檔，總不會錯了吧？是的，在我看來，這是最好最嚴謹的選擇。不過，需要提醒的是，官方文檔也是人寫出來的，是人難免會出錯，所以其實官方文檔也可能會有錯誤。比如之前我在閱讀W3C官方文檔時就發現了一處錯誤，是一篇關於background屬性的介紹。
- 錯誤寫法：background-size: 10em 10em;
- 正確寫法：background-size: 10em auto;
我於2017年12月6日給W3C官方提交了修改建議，後來在2018年1月13日被W3C官方採納了，說明這的確是個錯誤。
雖然官方文檔也可能會有錯誤，但是這種情況是少之又少的，而且一般都不會是原則性、很離譜的錯誤。總之，優先選擇官方文檔就沒錯了！還是那句話：不要完全相信任何非官方的技術資料！！！
最後的提醒
我寫的文章，也屬於非官方資料。
- 大家看的時候也要持保留態度，也是一樣，不要完全相信
- 官方資料大多都是英文，而且西方人的閱讀習慣和我們不太一樣，所以這其實給初學者帶來了不小的學習困難
- 《秒懂Java》系列的內容是以官方文檔為主要參考資料，經過一系列嚴謹查證後，最後再得出結論
- 我會儘力使用通俗易懂的語言，讓大家能夠輕鬆愉快地學到嚴謹又全面的知識
- 如果大家發現了我哪裡不嚴謹的，希望能夠直接指出，感激不盡
我一直都覺得：在學習技術的過程中，最重要的階段就是初學階段，你第一次接觸的學習資料極其關鍵，一定要找一份靠譜、優質的學習資料。這就好學習講普通話。
- 如果你一開始是跟著廣東人學習講普通話，那麼你的普通話可能就會帶有廣東口音，就算你後期改為跟著北京人學習普通話，且經過了長期的刻意訓練，可能還是會有那麼一點點的廣東口音
- 但是，如果你一開始就跟著北京人學習講普通話，那麼你的普通話從一開始就是非常正宗的，就算後面經常跟廣東人交流，也不會把自己的普通話給帶偏
github
簡介
最後，給大家介紹一個作為程式設計師（軟體開發工程師）必須要知道的網站：github。
- 它是全球最大的程式設計師交流網站
- 由於程式設計師以男性居多，所以它也被網友調侃為是全球最大的同性交流網站GayHub
全世界的程式設計師都可以將自己的編程作品（完整的軟體、程式碼片段等）上傳到github，共享給其他的程式設計師去閱讀、學習、下載、修改，所以你也可以理解為github是一個程式碼倉庫。這種將自己的程式碼分享、開放出去的操作，我們叫做開源，也就是開放源程式碼（Open Source Code）。
如果你立志要成為一名優秀的程式設計師，那麼就點擊「Sign up」註冊一個github帳號吧。
提高開發效率
以後你在開發過程會經常用到這個網站。比如當你不知道某個功能該如何實現時，就可以去github上搜索相關的程式碼，很多時候你想實現的功能，別人都已經實現過了，直接把別人寫好的優秀程式碼下載到自己的項目中即可。這樣的話，你就不用去親手寫這段程式碼了，極大地提高了開發效率。
學習交流
github集結了全世界各地的優秀程式設計師，他們開源了非常多的優秀作品，都值得我們細細品讀和學習，我們能從中學到非常多的程式碼編寫技巧、編程思想等，有助於提高我們自身的技術實力。
你也可以給別人的作品提交程式碼（比如修改建議、新的功能），成為該作品的貢獻者之一，與全世界的其他程式設計師一起來維護這個作品，讓這個作品越來越好。
當你的開發經驗積累到一定程度時，手裡肯定也攢了很多優秀的編程作品，你也可以考慮把它們開源到github。全世界的其他程式設計師也可以給你提交程式碼，跟你一起來維護這個作品，你必然也能從中學到不少技術。
這是我的github主頁：//github.com/CoderMJLee，我也很喜歡開源自己平時的編程作品，點擊Follow即可關注作者的動態。
更多的機會
github上有個點贊功能，別人給你的作品點一個贊，你就會得到一顆星星（star）。一般星星數量越多，就說明你的作品越受認可越優秀。一般有上千顆星星的作品，都算是不錯的作品。當然，星星數量並不是絕對的參考標準，不是說星星數量少的作品就一定不行。
現在很多公司的招聘需求中，都有直接表明：擁有或參與過github優秀作品是加分項。
當你在github上積累到一定程度時，也可能會有大廠HR主動邀請你加入他們團隊。在2017年初時，我曾收到過微軟HR的面試邀請，電話溝通了一番，由於當時我已經在創業，並且他們工作地點又在上海，就沒有考慮這次機會。當時也有聊到薪資要求，我說我之前是7位數年薪，她說只要達到技術要求，這個是沒有問題的。我舉這個例子，並不是想說明我的個人能力如何，因為這僅僅是面試邀請，面試是否能通過，這還是個未知數。我只不過是想藉助這個例子告訴大家github這個平台對我們來說很重要。
如果你是名初學者，現在也不用想太多，一步一步來，慢慢積累，積累到一定程度，機會自然會找上門，該有的都會有的！但是如果你沒積累好，就算會有機會擺在你面前，你也抓不住，眼睜睜看著機會從手中溜走！最後送大家一句我一直都非常喜歡的8個字：你若盛開，蝴蝶自來！加油！
