coding的時候，你應該要「先」學會什麼？
那麼，現在看下來我們差不多要學coding了，此時你/妳應該會選好IDE(整合開發環境)跟學習的語言，甚至已經在學習的路上了，不過我們還是先來談談寫程式前需要什麼樣的能力。
「咦？上一篇不是說直接下去寫就好嗎？」
是滴，單純是寫程式的話直接寫會讓你最快瞭解「現在的自己」喜不喜歡寫，但是如果想寫好、順暢地學習，你應該要專心在培養什麼能力呢？
因此這篇文章不只是在說「寫程式時」具備的能力，我其實會更強調「寫程式前」就必須具備的能力有哪些？
- Google，學會反問電腦問題
- 學會MECE思考，問自己問題
- 了解提問的藝術，問別人問題
接下來讓我們詳細介紹，其實中心思想非常單純，就是問題與解答要怎麼串接：
1.Google
正是寫程式的訓練讓我學會「如何Google」，你可能會想Google不是很容易嗎？輸入個關鍵字就能查到想查詢的東西，但沒有那麼簡單。寫程式的查詢，你必須學會「問一個好的問題」（這也跟AI蠻相關的，改天有機會會寫我對AI的理解，畢竟目前自己都投注在這一方面）什麼意思？
coding的問題只有兩種：就是How跟What開頭的問題。
而這裡面又有兩種問題：
第一種，如何做一個自己沒做過的東西：
要知道，程式語言的更新速度超級快，甚至一個生態系豐富的語言就會有一堆語法、功能、框架被製造
看看Javascript (遠目，一堆XX.js 真的很恐怖XXD。這也是開源軟體的紅利，第八章我們會提到，你就當成已經進入一個高速發展、高速演化的世界。既然那麼多東西，有辦法全部學會嗎？當然不可能！
自己能不能當個好的解決問題的人？
所以我說程式語言的學習是基於「問題導向的」，不要把自己當一個programmer , 而是problem solver.
透過發問，我們可以搜尋、歸納自己不懂、不會的東西，而這類的問題跟生活中大部分人打開Google在做的事情是一樣的，好比「如何寫履歷?」、「什麼是以核養綠」開始寫程式之後可能就是「什麼是CICD?」、「如何在網站使用動畫?」，很簡單吧？那是因為Google的自然語言處理技術做得非常好。
(看過最扯的是有人用台語拼音找影片，第一個就是他要找的) 這種問題Google到的都是直接的solution。
但是這樣是不夠的，有時候你想要找pdf、PPT檔案，想要精準符合搜尋欄位裡的字詞，必須學會一些特殊的指令，那就是你必須具備的能力之一：「透過下指令的方式使用Google」。
我不會教你怎麼做，因為你可以直接去Google，現在。
第二，寫程式的時候如果寫錯，我們就把這類錯誤稱為bug。
有太多時候我們自己寫程式會遇到一個bug，那基本上程式的bug有兩種：syntax error和 semantic error
第一種就是語法錯誤，可能你寫的不合格式、不存在語法（電腦看不懂）或者少了一些步驟、丟錯參數…….. 這部分你可能會想：「那我直接複製貼上bug information去查不就好了？」
確實，這是最快的方式，但我並不認為他可以「解決問題」。釐清一次，我們使用Google是為了「協助我們解決問題，我們向電腦提出我們的疑問」，所以你必須很清楚你的問題在哪裡。
正確的問題才有正確的答案
語法不熟並不是要解決「編輯器報錯的問題」而是「語法不熟、不清楚，為什麼這邊要這樣，看來自己還不明白」，所以你應該Google相關的技術文件、官方文檔，然後查看自己的程式碼，如此才能真的「靠你自己解決問題」。我不認為直接把error貼到Google上下一次就不會犯錯，它可以很快找到相關的錯誤與解決方法，但查看文件才能確保你真的了解了這項語法、這些用法，甚至可以發現你的思路是錯的，跟你想的完全不一樣，這麼舉例好了：
小明今天想要一張床，他不熟組裝技術，但他知道基本上需要買材料、工具，所以他把材料買回來之後開始組裝零件，組一組發現有個洞怎麼都穿不過去，所以上網查「如何穿過一個洞」而不是「如何組裝一張床」???????????????
覺得很荒謬嗎？但確實很多人是直接把error貼到Google上就這麼算了的，網路上有很多優秀的回答者，不過他們完全只能看到「你提出的問題」，但沒有被你提出、卻是你真正的問題，別人也幫不了你。清楚最基本的語法是很必要的。所以有些人說：「懂得越多，越覺得自己無知」。我也這麼覺得，因為當你發現這個問題背後其實藏了一個更貼近本質的問題，就會覺得不知道的自己很慚愧，這很正常也很有趣，反之如果只會提出「表面問題」的人，乍看之下很有經驗、碰過很多問題，事實上不是他們懂得更多，而是他們不知道真正的問題在哪裡。
第二種，就是連電腦都沒發現，可怕的semantic error，有時候程式運行順暢，可是你發現結果跟你想的差了十萬八千里，就是邏輯上出現了問題，特別是迴圈與控制，許多人容易打結。
這時候思考看看，你應該怎麼問問題呢？既然電腦不會告訴自己這是哪一種錯誤，我們必須深入思考：「哪裡有奇怪的味道(bad smell)？」
不熟悉、大概這樣、我記得應該……這些不清楚的程式碼片段要記得在寫的時候註解起來，當發生問題的時候優先檢查他們，並做好unit test(程式碼單獨執行)，確保每一行都是「我預期Y , 得到Y」。
如果發現有個地方跟自己想得不一樣，got it!
既然已經找到問題了，我們來想應該如何發問，想像一個情境：「老師指定你做一份蛋糕，可是你完全不知道蛋糕怎麽做，你只知道自己『不會做蛋糕』。」那要怎麼做？直接Google：「如何做蛋糕？」
所以我們只要把問題簡化成「如何」的問題就行了，因為這種問題的本質是自己「沒有想明白實作方法。」那麼找解方其實就是你應該問的。想寫一個將X加上3的函數，可是發現寫出來是X*3 + 8?
(這裡舉的例子有點誇張，總之就是函數沒寫對)
你可以用：「How to write a function that makes X add 3 in Python ?」
透過檢查別人的答案、對照自己的答案來思考，思考過別人的答案、了解他的思路之後就可以找到自己的思考漏洞。
所以要不厭其煩地Google，因為通常開發軟體最好的老師就是Google跟Stackoverflow（一個回答電腦相關問題的網站）了。以我修投資學時候為例，很多同學都會跟老師要PPT、答案，老師基本上也不知道怎麼弄或者懶得弄，但是很常用Google的我一下就把整本課本的簡報、答案、pdf找出來了，或者可以說很常用Google之後，在數位時代的獨立性會提高，因為很多資源其實都在網路上了，可以讓你在面對未知問題時不會那麼不知所措。
2.學會MECE的思考方式
窮舉 + 對比
這是來自於麥肯錫的思考原則，簡單來說就是：
「列對窮舉 ，互無遺漏 」。
咦？這不是商管人的夢幻職業：管理顧問的思考原則嗎？用在寫程式上？
是的，寫程式有一個語法叫做switch…case ，簡單一點則有if…else ，其實就是在做這件事情。流程控制，沒有好的控制流程，你的程式就是單向、不可逆的，單向的程式會讓你的程式碼很多很多條、而且非常不好讀。不可逆會讓你的程式容易重複、造成程式碼沒有效率、容易搞混平行流程等等……..
我們必須考慮「任何情況」確保「沒有漏掉可能的情況」，以及「列對」把完全相反的情況羅列出來以免思考偏誤。
你真的能夠發掘出所有問題嗎？其實並不容易，有了MECE的思考原則就不會讓自己的立場太過單一，如此一來面對深入的問題時就不會產生嚴重偏差。這點不只在程式思考上，專案管理、財務金融、生活上都需要用到。
通常工程師們少考慮一個情況，或者少多問一個前提，也就是並未考慮全部的問題時候，寫出來的程式就很可怕，因為要改東改西的，甚至少寫一個if包住就會讓程式無法運作，多問自己「還要考慮什麼？」是寫程式時非常需要的能力。我的商管文章也會提到MECE原則，總之就是多練習想廣闊一點，總是好的。
3.了解提問的藝術
嘿！你知道嗎？
提問是門學問，畢竟我們提問是因為我們不懂，這個不懂是「難以理解、無法得知」。
換句話說，如果你用過MECE自己想過、Google過找不到或者沒人回答、或者找到答案還是不好理解，就應該尋求他人的協助，向別人請教。
這也是PTT一直都很討厭伸手牌的原因，很多人都沒有先爬過文、自己查詢，反而直接問「月經問題」，其實是很不禮貌的，因為如果你根本就不想解決這個問題，為什麼別人要幫你解決？
那麼好的提問其實有很多種，我就不一一贅述了，這是coding系列文的其中一篇，簡單說明一下如何提問，不過既然我也把問題告訴你了，你其實應該知道怎麼回答。
基本上就是：
- 簡單描述問題本身
- 描述自己不懂的點
- 貼上相關/原本 的 錯誤/程式碼
- 敘述自己看到資料的思考
- 問 如何解/為什麼
如果還想知道更多，github上有個「提問的藝術」推薦大家都去看一下，會更清楚具體的提問情景。
另外這一章主要都是在講問問題，但其實解答問題也是一門藝術，不過篇幅有限就….有機會再寫好了XD
好文來自：Dennis Dsh
