fbpx

好煩哪!寫不出來啊啊啊????????

OK! 這應該是一個我認為現在最有效、最愜意,寫起來感覺比較良好的方式。

也就是我「寫程式時的思路」。

有太多的程式教學都是:「告訴你用法,給你一個範例,要你練習。」

「給他一條魚,不如給他一支魚竿。」

所以,誰說拿了釣竿就會釣魚?

我不認為把語法複製貼上,舉個例子給你看,就是程式教學。

真正的程式教學應該教思路、教方法,而語法的學習不應該佔據太大的篇幅。

但是現在的技術環境,的確很多都是流於語法導覽,尤其是網頁教學,然後特別是前端,為什麼呢?

因為改改語法就能寫出一個美美的網站,我得承認這樣的確很方便、也不可或缺,但是我覺得這些並不是一個老師要教給學生的,而是學生自己能夠學習的。

語法最重要、最根本的,偏偏這些個人都能夠看文件學會,老師要教的應該是「拆解問題、組織問題、解決問題」的方法。

老師應該教的是:拆解、組織、解決問題的方法

首先我得破除一個迷思,就是電影中你可能會看到一個戴著面具的駭客,霹哩啪拉就能打出一堆程式碼。那個在實際的工作環境中,幾乎不存在!

這部分我們會在:「第九講:寫程式到底是一個怎樣的情境」細說。

那麼正式來理解寫程式的思路,當然思路有了,接下來就是大量練習,我們要透過刻意練習來強化這套思考框架,藉由應用來真正達到內化,順暢解決問題,就是一名好的problem solver該具備的能力。

那麼這套流程是我改過的,啟蒙老師來自於一名Google本部的工程師,擅長語言是JavaScript 以及 Python。

我則結合了管理顧問的思考方式延伸出下列這套自己的方法。

WSPTT思考法,思路流程如下:

  1. Writing 畫出來,思考input , output
  2. Speaking 講人話
  3. Pseudo code 寫偽代碼
  4. Translation 翻譯code
  5. 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工程師的思考方式,相信是一套很管用的方法,也會讓你在寫程式時比較不會那麼不知所措,此外,多動手、複習語法才是練好一門語言的不二法門,否則還是不能在電腦前面迅速、熟練寫下程式的哦!

希望對您有所幫助,感謝您的觀看,我們下篇文章見!

 

Leave a Reply