ZDNet Taiwan - 必須面對的真相─五大程式設計迷思 - 名家專欄

註冊 | 登入 | RSS Feeds

ZDNet | Taiwan.CNET.com |

2010年2月9日

必須面對的真相─五大程式設計迷思

25則回應

李啟龍 2009/01/15 05:00:00

談程式設計的迷思前，我們先來看一下何謂程式語言？

程式語言是什麼

所謂程式語言，其實就跟中文、英文這些語言一樣，只是使用的對象不同。程式語言是與電腦溝通、讓電腦幫助我們完成想做的事情的唯一途徑。

程式語言的種類非常多，基本上可以分為『低階語言』和『高階語言』兩大類，低階語言包括機器語言與組合語言…等，而高階語言則包括C/C++、Pascal、Java、Cobol、Perl、Python、Visual Basic…等。

低階語言比高階語言的執行效率高，而且對於電腦硬體的控制性也較高；不過，低階語言的開發較為困難，語法結構與人類的使用習慣不太相同，較難以開發、閱讀、除錯與維護。

相較之下，高階語言為敘述性的語言，其語法結構與人類的語法使用習慣較為接近，較易開發、閱讀、除錯與維護；但其對於硬體的控制性較差，且執行效率也不及於低階語言。事實上，這也是C/C++、Pascal、Java、Cobol、Perl、Python、Visual Basic…等高階程式語言，廣被學習與使用的原因。

程式語言的五大迷失

經筆者觀察發現，很多人在學習程式語言、進行程式設計時，常會陷入以下五個迷思：

迷思一：需要讀資訊系，才能成為好的程式設計師！

NO！NO！NO！如果有讀資訊系，當然對於成為好的程式設計師有幫助，不過這並不是必要條件。

沒讀資訊相關科系，只要有興趣、肯努力、愛挑戰，一樣能成為很好的程式設計師。筆者就認識一些非資訊背景的程式設計高手，他們分別來自於數學系、企管系或是電子系…等，所以，不管有沒有讀資訊系，都可以成為好的程式設計師的啦！

迷思二：程式設計工具非常昂貴？！

NO！NO！NO！其實很多的程式設計工具是免費的，而且其功能也相當完善，甚至很多的程式設計工具還是中文化的。

比方說很多讀者曾學過的C語言，即有個叫做Dev-C++的免費中文化的程式設計工具，讀者可以直接在這個連結中搜尋『Dev-C++』這個計畫，裡面也有介紹提供下載的網址。

下圖為Dev-C++的視窗畫面。

（未完，請按下一頁繼續了解其他迷失）

繼續閱讀： >>

| 第1頁 | 第2頁 |

加入網路書籤>

對本則報導有任何意見或看法嗎?歡迎留言

25.louisfifty 於 2009/02/09 20:44 回應
萬分認同
我只是高中升
在國中時自修C#
雖然很辛苦
但用興趣可以彌補一切
之後擁有了資料庫設計與程式碼設計的基本概念之後
不錯
高中電腦老師的程式設計還不見得能考倒我
況且圖書館都有很多書可以借閱
有的還附有光碟
到現在正在自修VB、C++
其實只要有興趣
費用跟年紀及難易度其實都可以是零!!
感謝你的發文

24.匿名於 2009/02/02 12:52 回應
連結
電子新貴改賣雞排月賺十萬

今天的雞排新聞，唉～

23.匿名於 2009/01/31 21:29 回應
寫程式不如去賣雞排 ... 同意。

22.小布於 2009/01/25 16:57 回應
電影深夜加油站遇見蘇格拉底中有一句話說道知識不等於智慧而智慧是實踐知識後才會有的。知識可以在書中習得，Effective C++, Effective STL, ...Write solid code, Writing secure code..Design Pattern.. 很多數不完的知識。從見招拆招 try and error到經過不斷地練習跟實做之後，真正的融會貫通，那就是智慧跟經驗。呼應Jack所說得每一個觀點都有可取之處，在不同的狀況下，程式設計會有不同的思考方向，performance吃緊的考量之下，readablity必須要犧牲，充分的documentation跟comment則來補其不足。最後，態度也是非常重要的一環，有了智慧與經驗之後，是否能對source code management保有一貫的態度，這也決定的一個產品的品質。當然，公司文化、老闆重不重視、甚至產品的特性都是一些影響的factor。當你覺得寫程式不如去賣雞排的時候，那就去賣吧。以上是小弟的一點感想

21.Jason 於 2009/01/19 09:43 回應
Dear gorden,

看到你的回應，我可以感受到你是一個對於程式設計相當有興趣，但還不知道如何開始的朋友。
學習程式設計是一件有趣的事情，我相信只要有心的人，一定可以寫出程式，做出一些可以使用的作品，而且對於邏輯思考，也有一些幫助。
我可以給你的學習建議是：
第一步：先確立你的學習目標
你想要寫出哪方面的應用程式是很重要的，這關係到程式語言的選擇和學習動力的持續。比如說是網頁程式設計、手機程式設計、資訊競賽程式設計、專題發展程式設計….等等，不同的應用範疇，有不同的程式語言可以選擇。如果有確立明確的目標，可以維持住你的學習動力，畢竟沒有目標的船是永遠到不了終點的，所以，確立目標非常重，可以幫助你選擇適當的工具和維持學習動機。
第二步：找一本你可以理解的程式設計書籍
書不用太厚、範例不用太難，以你的能力能理解其中80％的內容為原則，慢慢自學，慢慢體會程式設計的奧妙和精髓。
第三步：實際動手寫程式並參酌網路資源
當具備基本的程式設計概念與能力之後，可以朝著你的學習目標前進，動手實作！！！當遇到問題時，再尋求身邊的朋友或網路資源的協助，把遇到的問題解決。
第四步：完成第一個作品之後再找下一個目標
恭喜你！當你完成第一個作品，其實你對於程式語言的架構，已經有些許瞭解，此時，可以設立下一個目標，繼續前進。程式語言之間，許多的語法或概念都有相通性，所謂一法通萬法通，未來你要再學習其他的程式語言，都會事半功倍了。

以上是我的建議，程式語言學習的方式，每個人不盡相同，提供你參考，希望你學習順利，加油 ^_^

Jason

20.gorden 於 2009/01/17 14:16 回應
啟龍兄，
看到你對於程式設計的有心人鼓勵的文字，讓我不自覺回應你的熱絡及用心。

謝謝你讓有心或是有意的人，如我，能夠看到原來學習程式設計，與科班與否無關，與有心無心、有意無意有關，這真是一個很好的消息。

我最近對程式設計有一定的感受，或說有一些些的興趣，但是入門無方，是以在這裏，我想問一個最簡單不過的問題：

對一個有心的非科班的入門者，你會建議如何學習程式設計或是整体的數位學習？
是否有一些啟發性的著作，或是描述有如你的行文一樣的入門書？

不可否認直接閱讀專業的書冊，對我來說是高難度。

我之想涉獵程式設計，是想了解這種語言，與日常生活中的語言有何差異性？
如何能夠很自然的轉換而習得？
也就是能夠用一般的語言思考方式來學習融入程式語言的設計？
我想學習原因，是因為網路的運用已經是生活的常態，但是背後的原理，卻是那麼的仰之彌深、鑽之彌堅，瞻之在前，忽焉在後，讓人有只在此山中，雲深不知處的感覺。
我想這種花非花、霧非霧的感覺，對你這樣的過來人，已經是了然於胸，也都是前塵往事，不過這些經驗，對於要準備登山的新學習程式設計者，會是最佳的建議。
還請你不忙的時候，能夠撥冗賜教。我的電子信箱theupperroom2007 (at) gmail.com ，先行謝謝你。問好。

19.inpines 於 2009/01/16 16:53 回應
這篇文章，我認為就內容來說，值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。

我認為所謂「程式語言一直在改變」的迷思，作者的意思不單單只是說程式語言沒有一直在改變的意思，而是還有更深層的涵義沒有表達出來。事實上，程式語言一直再改變是個事實，我們不該說它們沒有一直改變。而是這些改變並不會讓我們先前對程式語言學習的投資白費。

程式語言會不斷演化是必然的，「成熟」的程式語言反而是象徵衰退的開始。因為隨著時代的進步，程式設計的問題只會愈變愈複雜，造就了新的程式設計概念。如果程式語言太成熟，以致無法改變來加入新的程式設計概念，那麼它們將被時代所淘汰。所以，問題不在於程式語言是不是臻於成熟，因為改變是必然的，重點在於你投資在程式語言的學習並不會白費。

再來，作者提到「千萬不要認為電腦已經跑得很快了，就不注意演算方法的選擇。」我認為是正確的。但他舉例指出遞迴函式效率較不佳、比非遞迴寫法的程式容易做重複計算，建議大家儘量避免用非遞迴的寫法來進行程式寫作的說法，我就完全不能夠認同作者的看法。

沒有錯，遞迴函式的確比非遞迴的寫法會佔去更多的記憶體，但以空間換取時間的角度來看，說遞迴函式比非遞迴寫法更沒有效率，則是過份簡化的說法。即使以作者舉計算費式數列的遞迴函式的例子來看，遞迴函數可能有重複計算的問題，但到底費式數列的 n 值要多大，遞迴函數的執行速度才會發生顯著的影響，這卻是值得探討的問題。

如果在一般解決領域問題的條件限制上，都不見某種演算法的缺點，會產生顯著的影響，但卻能享受到該種演算法的優點，那麼我們是不是應該選用這樣的演算法來設計程式呢？答案想必是肯定的。這不是把問題推到硬體速度夠不夠快的問題，而是演算法的選擇應該透過客觀的分析與理性的思考，才能找到最適當的選擇。

這讓人也發現到程式設計常見的迷思，很容易誤導我們對程式開發的看法；太過相信經驗法則而缺乏對問題的深入思考，容易人云亦云地以為該用什麼演算法或避免什麼演算法，而那些都是程式設計師自以為是的偏見。

每一種演算法都有它的優缺點，我們應當針對問題的目標與限制來「思考」最適當的演算法，而非慣性地以為那一種方法用在每一種情況都比較好、或比較不好。因此作者建議儘量避免用非遞迴的寫法，進行程式的開發，我對此實在是感到不能認同。

更何況透過思考，遞迴函式重覆計算的問題並不難解決。例如我們可以在遞迴函數中，將已經計算過的數列項次值儲存下來，當過程中發現某個項次已經計算過了，我們可直接取值而避免再計算一次，這樣就可以增進遞迴函式的執行效能。而運用程式設計者的智慧，遞迴耗費大量記憶空間的限制，也並非不能克服。

有一位朋友就分享他在繪圖程式設計的經驗，他曾改進過填色的遞迴函式。原來一個點向四面擴散填滿顏色要用到大量的遞迴空間，但只要改變以線或區域為單位向四面擴散，就能大幅減少填色所需之遞迴空間，克服遞迴函式的先天限制。所以問題並不是遞迴可不可以用，而是程式設計者懂不懂得用思考來創新設計技巧；不懂得在解決問題上尋求挑戰與突破，那才是讓程式設計能力停滯不前的最可怕迷思呀。

完整觀點請參考本人在網誌發表的文章：連結