好煩哪！寫不出來啊啊啊????????
OK! 這應該是一個我認為現在最有效、最愜意，寫起來感覺比較良好的方式。
也就是我「寫程式時的思路」。
有太多的程式教學都是：「告訴你用法，給你一個範例，要你練習。」
「給他一條魚，不如給他一支魚竿。」
所以，誰說拿了釣竿就會釣魚？
我不認為把語法複製貼上，舉個例子給你看，就是程式教學。
真正的程式教學應該教思路、教方法，而語法的學習不應該佔據太大的篇幅。
但是現在的技術環境，的確很多都是流於語法導覽，尤其是網頁教學，然後特別是前端，為什麼呢？
因為改改語法就能寫出一個美美的網站，我得承認這樣的確很方便、也不可或缺，但是我覺得這些並不是一個老師要教給學生的，而是學生自己能夠學習的。
語法最重要、最根本的，偏偏這些個人都能夠看文件學會，老師要教的應該是「拆解問題、組織問題、解決問題」的方法。
老師應該教的是：拆解、組織、解決問題的方法
首先我得破除一個迷思，就是電影中你可能會看到一個戴著面具的駭客，霹哩啪拉就能打出一堆程式碼。那個在實際的工作環境中，幾乎不存在！
這部分我們會在：「第九講：寫程式到底是一個怎樣的情境」細說。
那麼正式來理解寫程式的思路，當然思路有了，接下來就是大量練習，我們要透過刻意練習來強化這套思考框架，藉由應用來真正達到內化，順暢解決問題，就是一名好的problem solver該具備的能力。
那麼這套流程是我改過的，啟蒙老師來自於一名Google本部的工程師，擅長語言是JavaScript 以及 Python。
我則結合了管理顧問的思考方式延伸出下列這套自己的方法。
WSPTT思考法，思路流程如下：
- Writing 畫出來，思考input , output
- Speaking 講人話
- Pseudo code 寫偽代碼
- Translation 翻譯code
- True 不要「裝」
第一步：畫出來，思考input、output
進去什麼，出來什麼？
我曾經上過麥肯錫與貝恩兩家有名顧問公司的課，簡單來說吧，管理顧問在寫研究報告的時候第一步，就是搭建「分析框架」。那寫程式也一樣，我們一定要很清楚輸入是什麼，輸出又是什麼。舉販賣機為例，你很清楚輸入是「10元銅板」然後按了一個按鈕，「碰！」輸出「鋁箔包綠茶」。寫程式的話就是：
10元 = 參數
按按鈕 = 觸發/函數
鋁箔包綠茶 = return
基本上你看到的任何應用程式都是由這三個因子組成的，開燈燈會亮、發動車子車會跑………，他們的運作一定都來自於一個trigger，而輸出成你想要的結果，沒錯吧？所以我們一定要很清楚到底應該要輸入什麼、輸出什麼。
此時如果一道題目是問你：「寫個提款機程式吧！」那麼第一步呢，其實不是直接敲鍵盤（啊不過腦袋很清楚的話就直接敲鍵盤啦！）而是簡單像我這樣寫：
def 提款(提款卡 , 密碼,提領金額 ):
return 現金
def 是define的意思，後面接函數的名稱，()裡面放參數（輸入）return是回傳的意思，就有點像計算機的” = “，後面放輸出。
因為我很常寫Python所以會這樣表示，你愛怎麼表示都可以，也可以：
func 提款(提款卡 , 密碼,提領金額):
return 現金
你先不要想任何的實作細節，也不要想變數A=變數B ，最直覺地寫下你認為需要什麼輸入、造成什麼輸出。其實這不只在程式上，我們在做人生規劃、專案管理的時候，也都要想想自己想投入什麼，造成什麼產出。
第二步：MECE思考，講人話
不要漏掉、不要重複，思考可能出現的情況
第一步我們算是搭好了分析框架的頭跟尾，但是中間呢？要怎麼把頭尾連起來，就需要邏輯性。此時可以簡單地想想要怎麼做，然後畫在紙上或者平板上驗證，當然，我個人會習慣以註解的形式打字，打什麼呢？打「該怎麼實現」的問題。
以剛剛的提款程式為例，我會先去思考提款這個流程有哪些需要注意的地方，也就是：「什麼情況下這個流程會出錯？」這是很重要的，我們其實可以先不想流程本身（也跟上一步有關，其實在思考輸入、輸出的過程中我們就大致知道了整套流程才對，巧妙吧？）記得我在上一篇文中提到的MECE原則嗎？真正做到不重不漏，就會直接用反面去思考，所以什麼情況下我們會無法提款呢？第一個就是參數輸入不全，對嗎？好比少了密碼、少了提領數字。所以簡單在你的程式碼寫上第一個if：
if 少了參數，ok，先不要想少了參數會怎樣，一樣，如果你的頭腦非常清楚，就可以直接順手寫下來，但我不建議這麼做，畢竟這裡舉的例子很簡單，但是在很多情況下順手寫下會發生什麼事情都會把腦袋搞亂。然後呢？不斷問自己然後呢才能做到不漏，比如：如果你的提款數字有問題其實還有可能是：帳戶的錢不夠，對吧？這裡你可能會興奮地寫下if account < 提款額度，沒錯，再來呢？密碼有沒有可能錯誤？有！所以 if 密碼錯誤 ：沒錯吧？注意到了嗎，所有的問題都環繞在參數上，感受到先寫出input的威力了嗎？如果我們先定義好input，就能夠方便發想到這些問題，相反地，直接敲程式碼往往會讓我們漏東漏西。搭建好if的流程後，我們就想if會發生什麼事情，比如：
if 提款卡 = null(沒有) or 密碼 = null or 提款金額 = null:
就說：「請輸入XX」。
所以這邊就是很簡單：根據參數來思考反面事件，然後思考怎麼處理缺失，處理缺失的方法也很多，就是思考該讓使用者回到程式的哪一步，好比沒有密碼，就讓他回到「提款機的登入流程」，以先前的販賣機來說，沒有投錢，就讓他回到：「可以投錢的流程」。這邊可以用flow chart來輔助，會更加清楚（flow chart很常拿來做系統分析，用在coding上當然也可以，但是我們可以訓練自己在腦中產生flow chart ，讓思考更加迅速）那怎麼處理錯誤呢？比如：提款金額 > account這一點，可以做個錯誤處理（印出錯誤或者跳到另外一個情況，好比問：要先除值嗎？）。這一步我們要把分析框架搭建完成，都用自然語言（人類說得話）寫就行。
第三步：寫偽代碼（Pseudo code）
啊！語法真的背不起來
其實上面的流程我就有用到偽代碼了，比如if 、def , 從這裡開始，我們要試著用工程師間的規範來寫code，也就是把剛剛只有自己看得懂的話寫成
別人看得懂的邏輯。
這裡有一套標準存在，當然如果你沒有要跟別人協作、是自己要寫的，那就還是寫自己看得懂的話也行，但是要改成用類似程式語言的語法，為什麼說類似呢？因為不用一樣，這算是蠻必要的：如果今天我忘記了某個語法怎麼辦？這是很常發生的情境，所以我們都可以用自己的語言代替，好比我忘了排序的語法是sort() 還是 排隊() ，那我就先寫上sort 這個標記就好。記住，這一階段要寫得很類似程式碼，但是遇到不會的語法就標記起來。
第四步：翻譯code
Google很重要，文件很重要，當個翻譯寫手
沒什麼好說的，就是把剛剛標記起來，不熟的語法查出來，然後寫成編輯器看得懂的code。此時才會真的在鍵盤快速打程式碼，所以思路很清晰、而且很熟相關語法的人通常都能打得很快，坐在電腦前稍微想一下就動手了。我自己在做過多項機器學習的數據分析之後，在對資料的操作也基本能達到這樣，就會有很會寫程式的假象XD
熟能生巧罷了，因為我們很習慣思考想要什麼、需要告訴電腦什麼，那接下來就只是語法熟練度的問題了，這在踩過多個syntax error的坑之後很快就能上手，我覺得初學者不用對語法感到太焦慮，不要怕錯才能成長，才會記憶深刻。
第五步 ：不要「裝」
算了管他的，copy and paste!
與其說他是第五步驟，不如說他是一個貫穿思考框架的原則：
「不要裝」意謂不要輕率地處理程式細節
如果我們在實現的過程中發現某一個步驟特別複雜， 就另外寫一個函數、類別來處理它，而不要草率複製貼上別人的程式碼、貼上類似的解決方案，因為你會把自己帶離問題，但問題是始終都要面對的。了解你正在做什麼，正把資料帶往哪一個地方就是一門程式設計的藝術，而這是很有趣的。
以上，就是我的思路過程，融合了管理顧問與Google工程師的思考方式，相信是一套很管用的方法，也會讓你在寫程式時比較不會那麼不知所措，此外，多動手、複習語法才是練好一門語言的不二法門，否則還是不能在電腦前面迅速、熟練寫下程式的哦！
希望對您有所幫助，感謝您的觀看，我們下篇文章見！
