從一個故事說起
在應用開發如此方便的今天，我總是會聽到有些人有這樣的疑問，“只是做 應用 開發的話，還有沒有必要學習諸如作業系統，編譯原理這樣的課程呢？”，亦或是會聽到這樣的話，“會用這個框架就行了，它底層是怎麼實現的不用去管。”還記得我在大一學 C 語言的時候，就聽過有同學說我以後是想從事 Java 開發的，C 語言這種學來應付一下考試就行，指標什麼的其他語言又沒有，就不用去管啦。
真的是這樣嗎？剛好今天看到一個有意思的故事，從故事中我看到了答案，這個故事是是艾薩克·阿西莫夫 的科幻鉅作《基地》中的一個片段。故事是這樣的：
在銀河系中，隨著戰爭的蔓延，文明從銀河系邊緣開始逐漸退化，許多星球雖然還保留著核電站等高科技產品，但是已經不知道它們是如何運作的。
而有這樣一顆小行星，我們暫且稱之為 科技星 吧，在大戰爆發前它蒐集了銀河系中的各種科學文獻，並且匯聚了一大批的頂尖科學家。這顆小行星沒有被捲入戰爭，而是將技術一直傳承下去。
科技星周圍的星球覬覦它所擁有的高科技，想將之奪取。而科技星又沒有自保的武裝力量，在這種情況下，科技星如何自保呢？這裡最有意思的地方，正是科技星所使用的科技宗教的戰略。
當後來其他星球上的高科技出現問題的時候，會向科技星求救。科技星就會派遣工程師前去維修，但是呢，他們將各種身份都進行包裝，比如，工程師不叫做工程師，而是叫做“僧侶”，核電站也不叫做核電站，而是叫“聖殿”，維修也不叫做“維修”，而是叫做“祈禱”，也就是說，對核電站維修這一項工作完全被宗教化了！
而此時科技星提供的說法是這樣，因為這顆星球上的人做了壞事，比如違反法規，發動戰爭等等，觸犯了神靈，所以神靈剝奪了他們使用能源的權力。而如果想要恢復能源，就必須對自己的行為懺悔，祈求神靈的原諒。所以當工程師進入核電站進行維修的時候，所有的星球居民一起下跪祈禱，而當核電站恢復的時候，大家紛紛稱頌神的偉大。
為什麼那些擁有核電站星球的人們會對來維修的工程師“膜拜祈禱”呢？其根本原因還是在於核電站這樣的高科技對他們而言是神祕的，未知的東西。 儘管他們擁有這樣高科技的東西，卻沒有與之匹配的認知和知識儲備。
再回過頭來看看一開始的問題，你是否明悟了呢？我們也是掌握著上層應用框架這種“高科技”，我們知道怎麼去配置，怎麼去呼叫，就像上面故事中普通星球的人知道怎麼啟動，關閉核電站一樣。但一旦出了無法解決的問題，或者是遇到了什麼效能瓶頸，似乎我們能做的，只能去各種技術群裡，找那些大神“祈禱”了。
再來說說人工智慧
在今天，人工智慧這個名詞已經逐漸為人們所熟知。而未來，人工智慧的應用場景只會越來越廣泛，面向 AI 程式設計也必然會是一種趨勢。
那麼現在從事於 Web 或是 Android 等應用開發的程式設計師需要去學習機器學習或是深度學習相關的知識嗎？我的回答是 YES 。有人說我又不想從事於人工智慧的開發工作，為什麼還要去學它呢呢？我想說的是，為了避免成為上面故事中那些普通星球的居民。再過幾年，當你碰到一個會跟你說話的機器人或是更加奇妙的事物的時候，我們應該是對它的一些實現細節感興趣，會有探究的慾望。而不是在那裡感慨著造物主真偉大，竟能造出一個這樣神奇的東西。
話又說回來，在機器學習或是深度學習的學習過程中其實也很容易陷入到這種只會呼叫上層 API 而不知底層原理模型的境地。因為在今天，有很多庫類都可以讓你輕鬆實現一條語句就直接使用某個演算法模型，所以很多人就不再專注於對底層模型原理的學習。在機器學習的學習過程中，相信大多數人應該都看過這樣一張圖，
我們來看看這張圖中 Hacking Skills 和 Substantive Expertise 的交界處，這裡叫 Danger Zone，即危險區。意思是如果你只會程式設計和呼叫機器學習的 API，調引數，那麼你就處於一種很危險的境地。
結語
一個好的程式設計師，不應當滿足於學習到了什麼新的技術或者學習了什麼新的演算法模型。真正有價值的東西，往往是那些人們不樂意去學的底層的，枯燥的內容。
我們應該認識到，單單隻會上層應用開發或只會調包調模型而不懂底層原理，那這種開發人員的知識體系便如空中閣樓。看起來華麗壯觀，但實際上卻地基不穩。一旦出現一點問題這座閣樓便會頃刻崩塌，並且無計可施，只能到處“祈禱”。
對未知的事務保持好奇，不斷學習，探究事物的本質，原理。在我看來，這才是程式設計師之道。
推薦閱讀 ：
從分治演算法到 MapReduce
Actor併發程式設計模型淺析
大資料儲存的進化史 --從 RAID 到 Hadoop Hdfs