⊙善用經驗學習

「不經一事，不長一智」

「不經一事，不長一智」這是古之明訓。「我走過的橋多於你走過的路；我吃過的鹽，比你吃過的飯多。」這是「依老賣老」、「嘲笑別人」的狂語，這種事件，經常發生在我們日常生活的周遭，簡單的說就是「經驗」的多與少而已。「經驗」一詞指個體在生活的活動中所經歷的一切事故，是指活動的結果；另指個體在生活中為適應環境要求所從事的一切活動，是指活動的歷程。換言之：經驗是個體在生活中的活動歷程或結果。誠如俗語所說：「凡走過必留下痕跡。」 此「痕跡」可以說就是經驗。此經驗是個體親自體驗而得，另外經驗亦可從書藉或別人的作為而獲得。

經驗要與學習相結合，才能獲得正向、美好或良善的成果。因「學習」旨在達成個體在知識、技能、情感和態度的改變。亦是由經驗而獲得知識或行為改變的歷程。坤良在國立高雄師範大學成教所進修時，師長的教誨：「成人的學習要善用經驗和資源。」即成人要能結合過去的經驗來學習，因而對事理的瞭解、事件的詮釋會有較周延的觀點與看法，因而在待人處事上亦較能「通權達變、知所進退」。

經驗有美好或痛苦的、有成功或失敗的，無論如何，經驗將影響我們的生活或作為。如因「守株待兔」而終日無成，「一朝被蛇咬，終身怕草繩」等。倘若能將成功或美好的經驗繼續發揚光大，踩著成功的軌跡，依循成功的經驗，終將有所作為。反之，將記取失敗或痛苦的教訓，痛定思痛、檢討反思、繼續奮鬥，亦終必有成功的一日。因之，經驗的重要，經驗與學習結合更是重要，坤良謹就經驗學習之心得，從「認識經驗與學習的關係」和「善用經驗學習」兩方面，簡述如下：

一、 認識經驗與學習的關係

經驗與學習的關係至為密切，因為： (一)學習是經驗不斷的改造：如林德曼(E.Linderman)的經驗主張，提出「經驗是成人學習者活的教科書」。教育家杜威(John Dewey)的「教育是經驗不斷的改造與重組」，教育是「屬於經驗，由於經驗和為著經驗」的。由此可知，成人學習是與經驗結合，在既有經驗基礎上不繼的改造與重組

(二)經驗是學習的重要資源：學習既是經驗的改造，成人如摒除經驗，則學習是空乏的，如諾爾斯(M.S.Knowles)提出成人教育學的重要特色之一是成人具有豐富而多樣化的經驗，且經驗是學習的重要資源，透過經驗的分享，成人即可從中學習，獲得實用的知能或達到態度的改變。

(三)經驗也可能是學習的阻力：並非所有的經驗均具有教育性，有些經驗是違反教育而導致經驗不良的發展和未能使經驗成長，或者個體先前所獲得不正確的經驗而形成「先入為主」的經驗，都會造成學習的阻力

由此可知，成人學習以經驗為基礎，並力求不斷的重組與改造，同時將經驗視為重要的學習資源，而在學習中，過去的好壞經驗都影響到學習的結果，甚至有時變成成人學習的阻力，可見成人的學習和經驗是無法脫節的。

專家評論: Scott Johnson：做一個快樂一生的程式師

IBM WebSphere 開發者技術期刊

級別: 入門

Scott Johnson, WebSphere Application Server JSP 團隊負責人, IBM

2005 年 8 月 17 日

快樂的程式師知道自己的擅長之處，也知道在那個他/她期望的有些像天上掉餡餅一樣的工作中到底涉及到什麼。受一篇關於普通程式師急於學習程式設計的文章的啟發，作者就此與我們分享了他的觀點。

高速通道和長途旅行

就程式設計，電腦科學博士、Google 的 Search Quality 總監寫了一篇很不錯的文章，名為“Teach Yourself Programming in Ten Years”。這篇文章中提出了一個大問題：為什麼人們這樣急於學習程式設計呢？是因為他們希望能夠速成呢，還是因為大家認為電腦是最容易學習的？不管什麼原因，做一個好的程式設計師並非快速學習的結果，而需要深入認真學習，並需要明智地選擇學習的內容。關於這點，本文給出了六條建議，供那些準備開始（或已經開始）用一生的時間實現做個好程式師的夢想的人參考。

	你是專業程式設計師嗎？(上)

朱仲傑　　2006/10/12

你是「專業」的程式設計師嗎？什麼是專業？我自己的定義是「使用自己所擅長的程式語言，快速且正確地解決問題的程式設計師。」這句話裡有兩個重要的關鍵字：「快速」與「正確」。正確是絕對必要的，如果最後的結果不正確，那不管是用了什麼最新的技術，或是到底多短的時間就完成等，其它的因素都是白廢的。至於怎樣才叫快速？這個比較沒有量化的標準，而且快速還可以再細分成：你寫程式的速度和寫出的程式的執行效能。

但業界的確有權威的標準，來判定你到底是不是專業的程式設計師。最簡單的方式，就是參加一些有時限的程式設計比賽，例如正在舉辦的Google Code Jam 2006。Google Code Jam分成了三個關卡，每個關卡都要你在有限的時間內，解決幾個問題（詳情請看Google網站）。問題有難易度之分，相對所分配到的分數也不同，而你所得到的分數會依據你解題的速度、正確度與效能給分。只要在時限內達成要求，就代表你至少有一定程度了。

筆者不幸在第一關就慘遭淘汰。經過一番自我檢討，在今年的比賽裡，我犯了幾個嚴重的錯誤。第一，我沒有詳細的閱讀比賽規則、看錯比賽時限、不熟悉比賽程式介面。我把第一、二關時間看錯，第一關是要在60分鐘內解決兩個問題（兩個問題滿分分別是250分和750分），第二關的時間75分鐘。而計時是從登入後就開始計算，我在chat room晃了一下才找到自己的比賽區，賽前又沒有去熟練比賽程式操作介面，摸索也用掉了一些時間，所以當我真正認真讀題目寫程式時，時間只剩不到50分鐘。

第二個錯誤是我太自以為是。我原本認為沒什麼好怕的，寫程式我熟練得很。可是這個比賽的目的，其實不是要你對於一個程式語言的語法到底有多熟練，而是如何去找出、設計出正確的解題方法，至於用到的語法都只是最基本的條件判斷式、迴圈，外加基本的API等等。解題的方式說穿了很簡單，只要動動腦筋，運用一些幾何、數學的基本常識或功式，依題目的需求，組合成正確的解答即可。所以你必需具備的反而是幾何、數學的基本能力，而不是程式語言到底有多熟練。

要在時限內正確的解決問題並不容易，尤其是在做專案時。有句玩笑話說，專案的Deadline就是訂出來讓人delay用的。如果時限已到，問題還沒有辦法100%解決呢？那你就要用你專業的判斷，配合當下的環境，把能得到最好結果的答案給交出去。程式比賽時間是無法延長的，專案的話就有許多談判的空間，如果你交出去的答案夠水準，在客戶面前談判的籌碼自然就多一些。Google Code Jam其中一個題目的滿分是250分。要拿到滿分很難，但按照給分的條件，就算你的解法沒有100%的正確，還是會有一定分數。所以別浪費時間在仔細的檢查為什麼程式沒有辦法100%通過測試，只要有80%以上，就趕快交卷(submit)，馬上去解另外一題來拿分數。

我犯的第三個錯就是浪費時間在程式檢查上，5個test case我只過了四個，我花了很多時間來找這個bug，結果不但沒有時間解第二題，連第一題也忘了submit(沒sumbit就是0分了)。我在莫名奇妙中結束了這屆的Google Code Jam，千金難買早知道啊。

想法才是效能的關鍵

在google code jam中，解題的速度很重要，程式執行的效能也不可缺。效能固然和花掉的CPU時間有關，但這個時間會依硬體效能的提升有些改變，我認為，程式設計人員在設計你的解法/演算法(algorithm)時的想法和態度，才是決定程式執行效能的關鍵。

舉個簡單的例子，請你設計一個程式，可以計算a加到b的總合(例如1加到100)，你會怎麼寫？很直覺的，這種重覆性的工作，可以交給迴圈來解決。是的，用迴圈是可以正確的解決這個問題，但我認為這是最不專業的解法。我們就算數學不好，也聽過高斯小時候的故事；話說高斯從小就非常的聰明且頑皮，有一天上課時，老師為了讓他不搗蛋，出了一個難題給他，要他計算1加到100的總合。老師以為可以讓高斯安靜一下子，沒想到高斯沒幾分鐘就把答案算出來了。後來推導出所謂等差數列的功式，也就是首項加末項乘以項數再除以二，以這個例子來說就是(a+b)*(b-a+1)/2 。短短一行程式碼就解決的問題，為什麼要用迴圈寫成好幾行呢？當數字大時，使用數學功式的程式執行的速度絕對比用迴圈還快上很多！

寫程式的態度應該是，把你所學會的所有知識中，找出最好的解決方法，而不是程式正確會跑就好。如果還有更好的方法是你還不會的，那就趕緊把它學會，日後好運用在你的程式裡。你也許會不以為然的說，解決這種小問題，幹嘛要計較這麼多。我不想在這討論程式該不該做最佳化的問題，網路上已經有太多類似的爭辯，不知大家有沒有聽過「格局決定結局，態度決定高度」這句話？設計程式的思維和邏輯也不是一朝一夕就能養成或是改變的，你想要成為頂尖專業的程式設計師，就要養成良好的思維習慣。（待續）