關於 如何快速增進程式功力...

最近有網友在Blog上問到關於學習程式設計的問題(如何快速增進程式功力...)，我也很開心nowshow幫我做了一些回覆。(其它潛水多年的朋友們，該是甦醒的時候了...)

其實我一直很想找個機會和大家聊聊『學習』這個主題，因為自己走了很多的冤枉路，所以總覺得有好多東西想分享。只是有時後工作忙，忘了，有時候寫著寫著發現詞不達意，放棄了。前陣子常這樣，說來你可能不相信，其實在這個Blog裡的已發表文章數量差不多只是所有所有文章數量的2/3，其他的我都沒寫完，擱著...久了就乾脆放棄不發表了。最近想打破這個限制，所以想到什麼寫什麼，也請讀到的朋友們原諒文章中用詞的隨性，畢竟這年頭『卸卸』之類的火星文充斥，我們這些老頭們寫的文章應該算工整了。

回頭談學習，如何快速增進程式功力...?
說來慚愧，但不怕各位見笑，打從我學習程式設計以來，到目前為止，只『付費』上過一次電腦課程，而且還是國小約莫3,4年級，此後，我從沒上過任何一堂課。程式設計幾乎都是自學。

請千萬別誤會，我不是說上課不重要，特別是自己身為講師，如果我讓大夥覺得上課不重要，豈不是滑天下之大稽? 首先，我雖然沒付費上過電腦課，但自從開始以程式設計謀生(我的第一個收費的專案，是在高中時代寫的台北市某校的招生系統，當時還是用Clipper配合讀卡機呢)之後，只要有業界的教育訓練我都盡可能參加，每次的TechED我也都想辦法到場(公司出錢。對，我也曾和大家一樣坐在下面乖乖當聽眾)，觀念和眼界的建立是相當重要的。我身邊也有一些朋友們，是透過資策會或是其他知名的教育訓練中心的套裝課程，開始進入程式設計的領域。也有不少是科班出身，然後投身資訊領域。這些養成對他們都有相當大的幫助。

但我要說的是，不管怎樣的養成，這絕對只是一個起頭，不管你曾經經過怎樣的訓練，你都只能拿到一張入場券，進入業界之後，才是真正挑戰和學習的開始。我相信幾乎每一個軟體開發從業人員都同意，如果你討厭常常學習新東西，目前的軟體業肯定不適合你。

我回頭想了一下最近15年，我比較我『學習』一門技術的時間，和『使用』一門技術的時間，大家要不要猜猜看是『學習』的時間多還是『使用』的時間多? 我發現，隨著近幾年技術演進的速度越來越快，我花在學習的時間越來越長(不過這也因為身為講師或前導廠商的我們在學習這門技術的當下，相對而言手邊的資源會比大夥來的少一些，技術愈成熟，學習資源其實就會愈多)。

在當前的資訊環境下，時常『學習新技術』來『解決問題』，絕對是優秀開發人員的特質。反過來講也成立，我幾乎在每一個優秀的開發人員身上，都看到『學習力』這個特質。有能力自己找到Resource(不管是透過書籍、影片、課程、研討會...)，持續學習和成長，絕對是一個重要的關鍵。請注意關鍵在學習新技術來解決問題，而不是漫無目的學新東西，或是道聽塗說看市場趨勢或風向就亂學。(解決問題這個目標是一切的根本，這待會說。)

但學習這件事情很有趣，你一定聽過『突飛猛進』這個字，武俠小說裡也有過某個蠢蛋被打通任督二脈之後，就突然習得絕世武功之類的情境。我覺得並非不可能，而關鍵就在你是否奠定了一個很扎實的基礎。怎麼說呢? 對我來說就是這樣，我第一個學的程式語言是 Basic，當年是Apple II時代，那種燒在ROM裡面的Basic語言，坦白說那時候我照著書上抄了N百個程式也搞不清楚它在幹嘛。錯了也不知道該怎麼改，當時我是國小四年級左右，連英文單字都還有點問題。但興趣卻慢慢培養了起來。(我一直覺得，好的養成書籍或授課講師，把學員帶(教)到有興趣，讓學員願意自己去找答案，比把知識硬灌給學員來的重要多了)

一直到國中，我有機會自修學習C, Assembly(當時施威銘先生的書對我有相當大的幫助)，我要很認真的說，C和Assembly對我的工作完全沒幫助，但卻對我日後的學習奠定下了一個難以磨滅的影響和超級穩固的基礎。在這邊我要說的是，你越熟悉了解某種技術基礎的運作概念，越能夠全盤掌握，觸類旁通。最近這幾年大家都在談Design Pattern，UML，或是TDD...等，每隔一段時間就會有新名詞。但我要說的是，如果你對基本物件導向程式設計沒有足夠的自信(沒有足夠的認識)，我建議你真的要考慮從基本開始，穩扎穩打才是王道。

如果你不知道繼承的意義(為何要有繼承的機制?) 如果你搞不清楚類別和介面的使用時機，如果你對於抽象類別、泛型、多重繼承這些概念還有些陌生，或是你不曾從頭到尾寫過一個類別，用類別表達某一個實體(諸如訂單、一個功能、或是設計過一個資料存取機制...)，那千萬別去碰那些其它聽起來更高深的東西。因為，你的基礎愈扎實，學習才能愈有效。否則那些新東西只會擾亂你的大腦。時常檢視一下自己的基礎，發現不足之處就趕快補齊，在台灣，身為開發人員，我們要學習的東西很多，沒有哪一個人敢說自己什麼都會的，總是有不足之處，古人『聞過則喜』， 資訊人員則是『聞不懂則喜』。趕快補齊，學到了(用過的)才是你的，相信我，越基礎的東西越重要。

有了好的基礎，加上持續且足夠的『學習力』，你即便不出類拔萃但大概也會是工作場合中所謂的『人才』了，接著，一個相當重要的關鍵能力，就是學習培養自己『解決問題的能力』。

說真的，這麼多年下來我的感受是，一個開發人員(或是IT人員)與其說學習寫好程式，不如說學習培養自己解決問題的能力。資訊科學是應用科學，尤其我們都在業界工作，不是在學術單位，『能用』才是王道，『能解決問題』才是所有事情的關鍵。千萬別忘記，你學習的幾乎所有東西，都是為了解決相對應的特定問題。例如匿名網友說到的，程式設計裡面的遞迴、物件導向...等技術，都是為了解決問題、或對問題提供更好的解決方案。

我自己的經驗，所謂『程式開發』就是等同於『問題解決』，一個一個的問題，一個一個慢慢面對、處理，面對客戶需求時要怎麼達成? 為了效能該怎麼規畫? 如何讓專案團隊更快速的開發和合作? Build完之後多少個Error, 該怎麼解決? 測完之後多少個Bug、該如何修改? 無法實作時該怎麼walkaround? 碰到技術障礙或瓶頸該怎麼面對? ... 每一個IT人員或開發人員每天的工作幾乎都是 『問題→思考→解決方案→行動』，然後一直是這樣的循環。

整個關鍵都在『培養自己解決問題的能力』，不管是Debug、或是Creat Solutions，都是一樣的。不管你的角色是PM、SA、SD、Developer、Presale...幾乎放諸四海皆準。

但很有趣的是，我曾經看過一些開發人員(許多是我的合作夥伴、學員、或同事)超級討厭問題、不想自己找解決方案，或對問題完全沒有思考能力...這幾個現象, 曾經讓我很不解，如果開發人員超級討厭問題，不曾享受過那種解決問題後的喜悅和成就感，表示他絕對選錯行，現今的軟體產業會榨乾他，他很可能會活在水深火熱之中。換工作的次數會很頻繁，直到他放棄這個行業為止。

不想『自己』找解決方案, 表示該員有些投機或懶惰, 就算他很聰明，在這個行業大概也只能待個幾年，我偶而會看到一些開發人員對於新問題常常直接放棄(請注意，不是真的束手無策，是『直接放棄』)然後立即找外援，他的工作模式是『找範本->改程式->碰到問題->找人幫忙』，而不是『規劃->寫程式->碰到問題->找解決方法』，在Google誕生之前，這類開發人員的壽命很短，常常夭折，多半靠身邊的同事或高手幫他解決問題，擅長人際關係遠超過程式設計。但Google誕生之後，有許多此類開發人員無形中多了一個虛擬的幫手，上焉者善於利用工具，也在業界找到了安身立命的空間。但我要說的是，如果是初學者真的無可厚非，大夥都是從零開始，朋友們技術人員互相幫忙也是常有，但如果在業界待了一兩年，卻還是始終只靠別人幫忙解決問題，那恐怕不是長久之計。

對問題沒有思考能力(表現出來的現象就是毫無頭緒，連要怎麼try都不知道)，是超級慘的一種狀況，我相信幾乎每一個人都曾經有過這樣的經驗(連身為講師的我們也不例外)，但如果你根基扎實，學習力強，很快的就能脫離這個狀況。會發生這樣的狀況，很可能是因為基礎知識不足...這時候，重新學習把基礎補齊是唯一的解決方案，也有可能是過去不常靠自己解決問題，那恭喜你，終於碰到成長的機會了。盡量自己試試看，不要放棄，你自己解決的問題越多，培養出的能力就越大。

我還看過一些更有趣的現象，有一些開發人員，碰到了某個狀況，或是某個bugs怎麼也不過，屢try屢錯， 屢錯又try, try了又錯，但神奇的是，他從不改變方法，不仔細看錯誤訊息(常常是因為看不懂, 也不google一下 ; 或是google了關鍵字還打錯)，也不努力去思考出錯的原因，就是用同樣的方法猛try，...會try出答案才有鬼咧。

石滋宜博士（前中國生產力中心負責人），曾說：「什麼是笨？ 就是老是用同樣的方法做事，卻期待會有不同結果的人。」

碰到問題找答案，我覺得是軟體開發這個工作當中最有趣(最有成就感)的部分，卻也是某些人認為最討厭(最痛苦)的部份，我只能說，近幾年來放眼望去每一個知名技術Blog的作者，或是我所認識的MVP，沒有一個不是解決問題的高手。很多問題看似無解，都能被大夥找到walkaround或是釜底抽薪的解決方案。在業界裡面，其實你很難定義何謂程式設計高手，但卻常常能看到，某人一出馬問題就能被解決，此之謂『專家』是也。

最後，我以前老闆說過一句話，我印象深刻也奉行不渝，他說：『你的時間在哪裡，你的成就就在裡哪。』對我而言，幾乎是金科玉律，也是我親身體驗的經歷。很多事情沒有捷徑，你的時間在哪裡，你的成就就在裡哪。