the above is from :http://www.cgs.tw/nucleus/blog/1
C/C++ 的執行效率，Java的可攜性，Delphi的多樣化VCL ，.Net的強大功能。
我 20 年前學程式，是從 Basic、C、Pascal 轉進到 SQL(這個十年前我也不會), Java , C++ , Delphi 等等物件導向的世界，也從主從式變成 3-tier ，甚至網頁介面，中間也學過其他領域如驅動程式 ,Window CE ,PalmOS ,多媒體等。
最近看到一則關於 Google 提供了程式碼搜尋(Google Code Search)的新聞 ,Google 針對各網站上的壓縮檔、SourceForge(很多開放原始碼的程式碼及安裝檔下載站台)及Google Code(Google 程式碼及開放原始碼)，讓程式設計師可以快速的搜尋網路上諸多公開的程式碼，迅速找到可以參考的資料。我試用了一下這個服務，他會查詢壓縮檔內的原始程式碼，可以說是比原本的 Google Search 又再進了一大步，如果你不會用特定的軟體 API，有時這樣就可以讓你迅速的找到網路上的範例。他也可以限定程式語言，所以我想不論對新進或資深程式設計師都會有很大的幫助。
Google 並不是網路上唯一一家提供通用的程式碼搜尋服務的公司，O'Reilly這家著名的電腦書出版商，也提供旗下數百本電腦書的原始碼搜尋，有興趣的人可以拜訪後面這個Code Search of O'Reilly Labs。如果你有時找不到適當的程式來參考，不妨試看看 Google 及 O'Reilly Labs 的這項服務，說不定你遇到的問題很快就能迎刃而解。
Google 並不是網路上唯一一家提供通用的程式碼搜尋服務的公司，O'Reilly這家著名的電腦書出版商，也提供旗下數百本電腦書的原始碼搜尋，有興趣的人可以拜訪後面這個Code Search of O'Reilly Labs。如果你有時找不到適當的程式來參考，不妨試看看 Google 及 O'Reilly Labs 的這項服務，說不定你遇到的問題很快就能迎刃而解。
或許就像『隔行如隔山』的俗諺，其實現在的程式語言也分支出來許多不同的應用，從寫應用程式的 C/Delphi/Java/.Net ，到網頁的語言如 PHP/ASP/JSP，甚至後端 RDBMS的 Oracle PL/SQL , MS T-SQL , MySQL ，或是 Shell Script 如 Perl 等等都有各自不同的語法，甚至如 Java 這種跨平台的語言都有版本不同，產生的結果不同的問題，或是 Unix 跟 Windows 產生的結果不同等問題。
那為什麼演算法和資料結構會成為寫程式的人必學的兩個科目呢？甚至有人寫下了如程式=資料結構+演算法之類的話語 .
基本上演算法是為了某些特殊的目的 ,如排序 ,字串比對 ,搜尋 ,矩陣 ,壓縮 ,加密等等而發展出來 ,因應硬體及儲存空間 ,計算效率等等的不同需要而會有所不同 .所以同樣的排序 ,可能有數種演算法可供選擇 .程式設計師可能要因應不同的環境選擇適當的演算法 ,因此對各種類似目的的演算法的效率或限制應多所了解 .資料結構方面 ,則是討論資料儲存在儲存媒介的方式 ,由於資料的儲存方式跟數量多寡 ,資料的分佈 ,甚至搜尋資料的速度等等息息相關 .因此資料結構有時也會跟演算法採用何種方式有關 .當選定了資料處理的方式 ,演算法和資料結構就必須依靠程式設計者的智慧來抉擇 ,資料透過程式的處理可以成為有效的資訊 ,其中的奧妙就是由演算法和資料結構來完成 .
基本上演算法是為了某些特殊的目的 ,如排序 ,字串比對 ,搜尋 ,矩陣 ,壓縮 ,加密等等而發展出來 ,因應硬體及儲存空間 ,計算效率等等的不同需要而會有所不同 .所以同樣的排序 ,可能有數種演算法可供選擇 .程式設計師可能要因應不同的環境選擇適當的演算法 ,因此對各種類似目的的演算法的效率或限制應多所了解 .資料結構方面 ,則是討論資料儲存在儲存媒介的方式 ,由於資料的儲存方式跟數量多寡 ,資料的分佈 ,甚至搜尋資料的速度等等息息相關 .因此資料結構有時也會跟演算法採用何種方式有關 .當選定了資料處理的方式 ,演算法和資料結構就必須依靠程式設計者的智慧來抉擇 ,資料透過程式的處理可以成為有效的資訊 ,其中的奧妙就是由演算法和資料結構來完成 .
第二個則是 ,是藍圖 ,是抽象化概念
我在學校開始寫程式的時候 ,想的都是CODE和演算法 ,腦袋裡都是 if else switch... 等等的code和變數名稱(報主按 ,我都不會想到這些說 :),到了專職寫程式後一年左右 ,在想程式的時候 ,腦袋裡看到是程式的主結構/副結構, 縱橫交錯的樣子 ,反而沒看到code的影子了 ,等到真的要寫code時 ,再像蓋房子灌漿一樣灌進去 ,等到做好時 ,把眼光拉遠 ,你會發現 ,整個結構 ,會很漂亮(如果這期間你的價值觀都沒變的話) .至少會符合你當初的期望 . 如果 ,這間房子大一點 ,要很多人做 ,這種方式就會很有用了 .也許因為自己不算本科出身 ,開始寫程式前沒有接觸軟體的方法論 ,等到寫過一些程式之後 ,看到像 Booch寫的書 ,就很有感受 .現在回頭想想 ,要是當初沒寫過程式 ,就看到這些書 ,可能就會把自己的興緻搞壞 ,反而一輩子都不會去碰吧 .不過 ,即便是這個領域 ,發展也是很快速 ,可以參考的資料很多 ,像是各領域有各自的pattern(e-commerice,j2ee,server side,system level...) ,需要時挑著學就好了 .不過 ,了解pattern 的文化 ,知道基本pattern就是基本要花的功夫了 .(報主按 ,好像我該去做功課了 ,什麼 pattern 都不會)
第三個 ,是角色扮演
在台灣(報主按 ,應該不只台灣) ,常常是一個人 ,要做SA ,SD , 兼下海寫程式 .面對這種事 ,最怕自己把角色混在一起 ,因為自己兼具設計和實作的角色 ,在設計時 ,腦袋一邊想著程式碼 .現在我在面對這種狀況時 ,我會把時間切開 ,譬如 ,早上做SA ,下午做SD ,明天再開始寫code .想在玩RPG 一樣 ,當下專心扮演你現在的角色 ,應該是一個蠻好的策略 .PS: 不過 ,印象裡 ,還沒看過 ,身兼挑磚塊跟建築繪圖都做的人 ^.^(報主按 ,達文西算不算呢 ,不過他算超級天才級的)
第四是軟體的價值與人性設計
軟體是給人用的 ,建築是給人住的 ,看現代建築 ,都強調實用性 ,再強調其附加功能 ,強調動線設計... 各時代的建築都和當代思想 ,當地的文化 ,有關 (也會有建築反過來影響文化的現象) 現在軟體產業 ,也在朝全球化的方向走 .最近看商業周刊 ,有家印度公司 ,準備進軍台灣 ,遇到最大的問題 ,就是要突破文化藩籬 .昨天看到遊戲橘子執行長的專訪 ,說到當年他想進入美國市場 ,卻在用一群台灣人 ,在台灣就把整套遊戲完成 ,結果當然就是可預期的失敗 .( 報主按 ,可是美國遊戲沒用台灣人 ,也能打入台灣市場 ,任天堂和新力應該也沒用台灣人 ,台灣還是會接受這些電視遊樂器呀 ,軟體沒有品質 ,是打不進去最大的市場的 ,我不覺得遊戲橘子的執行長有足夠的世界觀),他說的一個重點 ,遊戲是文化的產物 ,總的來說 ,軟體也是文化的產物 ,微軟的Office ,可以做成各語系發行 ,但是(報主按 ,那是夠品質), 還是針對各國的習慣做修改 ,增加功能 ,當一個軟體 ,確實符合了使用者的需要 ,才會被市場接受 ,才能獲利 ,在這方面 ,各種軟體所注重的地方都不一樣 ,在軟體開發之前 ,就要確定清楚 ,成為開發小組的共識 ,試想 ,要是做一個行政系統 ,開發小組裡 ,愛玩遊戲的組員 ,卻整天想著 ,做"華麗"的介面 ,對產品來說 ,就不是一件好事囉 .
後記
1.Design patterns有英文版 CD版 ,中文版是葉秉哲先生翻譯的 ,值得一看 .現在在sun 的網站上 ,也針對java 2 enterprise edition(J2EE),整理出design pattern型錄 ,可以下載看看 .IBM 在java平台上發展的一套framework(San Francisco) ,也出了一本薄薄 ,貴貴的書 ,整理出裡頭用到的pattern ,評價不錯 , 不過 ,我還沒看完.....(報主按 ,小馬真努力)
這領域可以找到的資料太多了 ,這裡有蠻多的 ,可以參考 http://www.hillside.net/patterns/patterns.html .
另外除了設計階段 ,分析階段 ,也有pattern可用 ,可以參考 Martin Flower的網站 http://www.martinfowler.com/
另外 ,我蠻推薦以前旗標翻譯的一系列微軟專案管理的書 ,以前還是小工程師時就在看 ,現在還是偶而會拿出來翻翻 .
好的函式：
我在學校開始寫程式的時候 ,想的都是CODE和演算法 ,腦袋裡都是 if else switch... 等等的code和變數名稱(報主按 ,我都不會想到這些說 :),到了專職寫程式後一年左右 ,在想程式的時候 ,腦袋裡看到是程式的主結構/副結構, 縱橫交錯的樣子 ,反而沒看到code的影子了 ,等到真的要寫code時 ,再像蓋房子灌漿一樣灌進去 ,等到做好時 ,把眼光拉遠 ,你會發現 ,整個結構 ,會很漂亮(如果這期間你的價值觀都沒變的話) .至少會符合你當初的期望 . 如果 ,這間房子大一點 ,要很多人做 ,這種方式就會很有用了 .也許因為自己不算本科出身 ,開始寫程式前沒有接觸軟體的方法論 ,等到寫過一些程式之後 ,看到像 Booch寫的書 ,就很有感受 .現在回頭想想 ,要是當初沒寫過程式 ,就看到這些書 ,可能就會把自己的興緻搞壞 ,反而一輩子都不會去碰吧 .不過 ,即便是這個領域 ,發展也是很快速 ,可以參考的資料很多 ,像是各領域有各自的pattern(e-commerice,j2ee,server side,system level...) ,需要時挑著學就好了 .不過 ,了解pattern 的文化 ,知道基本pattern就是基本要花的功夫了 .(報主按 ,好像我該去做功課了 ,什麼 pattern 都不會)
第三個 ,是角色扮演
在台灣(報主按 ,應該不只台灣) ,常常是一個人 ,要做SA ,SD , 兼下海寫程式 .面對這種事 ,最怕自己把角色混在一起 ,因為自己兼具設計和實作的角色 ,在設計時 ,腦袋一邊想著程式碼 .現在我在面對這種狀況時 ,我會把時間切開 ,譬如 ,早上做SA ,下午做SD ,明天再開始寫code .想在玩RPG 一樣 ,當下專心扮演你現在的角色 ,應該是一個蠻好的策略 .PS: 不過 ,印象裡 ,還沒看過 ,身兼挑磚塊跟建築繪圖都做的人 ^.^(報主按 ,達文西算不算呢 ,不過他算超級天才級的)
第四是軟體的價值與人性設計
軟體是給人用的 ,建築是給人住的 ,看現代建築 ,都強調實用性 ,再強調其附加功能 ,強調動線設計... 各時代的建築都和當代思想 ,當地的文化 ,有關 (也會有建築反過來影響文化的現象) 現在軟體產業 ,也在朝全球化的方向走 .最近看商業周刊 ,有家印度公司 ,準備進軍台灣 ,遇到最大的問題 ,就是要突破文化藩籬 .昨天看到遊戲橘子執行長的專訪 ,說到當年他想進入美國市場 ,卻在用一群台灣人 ,在台灣就把整套遊戲完成 ,結果當然就是可預期的失敗 .( 報主按 ,可是美國遊戲沒用台灣人 ,也能打入台灣市場 ,任天堂和新力應該也沒用台灣人 ,台灣還是會接受這些電視遊樂器呀 ,軟體沒有品質 ,是打不進去最大的市場的 ,我不覺得遊戲橘子的執行長有足夠的世界觀),他說的一個重點 ,遊戲是文化的產物 ,總的來說 ,軟體也是文化的產物 ,微軟的Office ,可以做成各語系發行 ,但是(報主按 ,那是夠品質), 還是針對各國的習慣做修改 ,增加功能 ,當一個軟體 ,確實符合了使用者的需要 ,才會被市場接受 ,才能獲利 ,在這方面 ,各種軟體所注重的地方都不一樣 ,在軟體開發之前 ,就要確定清楚 ,成為開發小組的共識 ,試想 ,要是做一個行政系統 ,開發小組裡 ,愛玩遊戲的組員 ,卻整天想著 ,做"華麗"的介面 ,對產品來說 ,就不是一件好事囉 .
後記
1.Design patterns有英文版 CD版 ,中文版是葉秉哲先生翻譯的 ,值得一看 .現在在sun 的網站上 ,也針對java 2 enterprise edition(J2EE),整理出design pattern型錄 ,可以下載看看 .IBM 在java平台上發展的一套framework(San Francisco) ,也出了一本薄薄 ,貴貴的書 ,整理出裡頭用到的pattern ,評價不錯 , 不過 ,我還沒看完.....(報主按 ,小馬真努力)
這領域可以找到的資料太多了 ,這裡有蠻多的 ,可以參考 http://www.hillside.net/patterns/patterns.html .
另外除了設計階段 ,分析階段 ,也有pattern可用 ,可以參考 Martin Flower的網站 http://www.martinfowler.com/
另外 ,我蠻推薦以前旗標翻譯的一系列微軟專案管理的書 ,以前還是小工程師時就在看 ,現在還是偶而會拿出來翻翻 .
好的函式：
在很多程式語言中都有提供函式的設計方法 ,但是什麼樣的寫法才能寫出較好的函式 ,卻未必有這麼多人會了解 .一般而言 ,一個好的函式大概有以下幾個特點 ：
一.取個好名字
一個函式有個好名字 ,可以讓人一眼就看出來他的目的為何 .一般建議的函式長度約在 20-35個英文字左右 ,可以讓人比較容易記憶名稱 ,不過以中國人來 ,我覺得 15-20字可能就是一個較適合我們記憶的長度 ,在命名時 ,類似的函式動作 ,名稱亦儘量取得類似一點 ,比教方便別人了解函式的可能用途 .
二.函式單純化
函式的目地儘量單純 ,最好只作特定的事 ,這樣作可能要付出的成本是程式可能效率較差 ,因為呼叫每一個函式都要花時間 ,但是可以得到的好處則是除錯比較容易 ,經過調查指出 ,一個以較單純程式碼寫出來的程式 ,其錯誤發生的機率較低 ,修護錯誤的成本也較低 .
三.降低函式間的相關性
一般而言 ,為了降低程式間彼此的依賴性 ,函式傳遞的變數最好儘量簡化 ,但這並不代表我們可以多用整體變數來傳遞數值 ,一般而言 ,會儘量建議少用整體變數來傳遞數值 ,因為整個數值可能會因別的函式修改而變動（多工系統）.
四.適當的長度
由於每個人對程式理解的程式不一 ,一般建議的函式長度最好介於100-200 行之間 ,這並沒有一個絕對的標準 ,經過研究顯示 ,太短的函式 ,未必見得可以降低錯誤的發生 ,但是因為太長的程式很難有人能看懂 ,因此才會有 100-200行的限制 .
五.適當的防錯性
由於整個程式可能由不同的人撰寫 ,我們不能先假設 ,傳進來的參數都會依照我們所想像 ,因此在函式中 ,應該對傳進來的變數進行相當的檢驗 ,避免傳進錯誤參數時 ,得到預期以外的結果 .
六.參數傳遞的基本原則
參數的排列最好依照"輸入-修改-輸出"的順序 ,這種原則並沒有強制性 ,但在你的程式裡 ,應該保持同樣的原則傳遞參數 .如果有不必要的參數 ,請刪除它的存在 ,代表狀態或錯誤訊息的變數則放在最後 .傳遞的參數亦不宜過多 ,一般建議最多 7個 .
一.取個好名字
一個函式有個好名字 ,可以讓人一眼就看出來他的目的為何 .一般建議的函式長度約在 20-35個英文字左右 ,可以讓人比較容易記憶名稱 ,不過以中國人來 ,我覺得 15-20字可能就是一個較適合我們記憶的長度 ,在命名時 ,類似的函式動作 ,名稱亦儘量取得類似一點 ,比教方便別人了解函式的可能用途 .
二.函式單純化
函式的目地儘量單純 ,最好只作特定的事 ,這樣作可能要付出的成本是程式可能效率較差 ,因為呼叫每一個函式都要花時間 ,但是可以得到的好處則是除錯比較容易 ,經過調查指出 ,一個以較單純程式碼寫出來的程式 ,其錯誤發生的機率較低 ,修護錯誤的成本也較低 .
三.降低函式間的相關性
一般而言 ,為了降低程式間彼此的依賴性 ,函式傳遞的變數最好儘量簡化 ,但這並不代表我們可以多用整體變數來傳遞數值 ,一般而言 ,會儘量建議少用整體變數來傳遞數值 ,因為整個數值可能會因別的函式修改而變動（多工系統）.
四.適當的長度
由於每個人對程式理解的程式不一 ,一般建議的函式長度最好介於100-200 行之間 ,這並沒有一個絕對的標準 ,經過研究顯示 ,太短的函式 ,未必見得可以降低錯誤的發生 ,但是因為太長的程式很難有人能看懂 ,因此才會有 100-200行的限制 .
五.適當的防錯性
由於整個程式可能由不同的人撰寫 ,我們不能先假設 ,傳進來的參數都會依照我們所想像 ,因此在函式中 ,應該對傳進來的變數進行相當的檢驗 ,避免傳進錯誤參數時 ,得到預期以外的結果 .
六.參數傳遞的基本原則
參數的排列最好依照"輸入-修改-輸出"的順序 ,這種原則並沒有強制性 ,但在你的程式裡 ,應該保持同樣的原則傳遞參數 .如果有不必要的參數 ,請刪除它的存在 ,代表狀態或錯誤訊息的變數則放在最後 .傳遞的參數亦不宜過多 ,一般建議最多 7個 .
跨平台的相容問題：
在 Java 宣稱這個語言可在不同語言執行前 ,除了 C語言外 ,大部份的程式語言的跨平台執行能力都不強 ,即使是 C, 你會發覺其實跨平台執行能力 ,其實還是很有限 ,多半集中在一些使用者介面主要在文字模式下 .
當你開始要操作繪圖介面 ,你會發現每個系統要學的東西可能就不一樣 ,Unix 下可能會用 Xlib , Win32 下可能會用 Win32 SDK ,DirectX , MacOS 可能又有新的一套 .但是這部份通常不會認為太複雜 ,因為沒有這部份的底層都得用不同的驅動方式 .
但是比較麻煩的大概是同樣一個檔在不同的平台間會有不同的表現, 以 Java Applet 而言 ,如果當你設計 Java 程式時 ,你會發現 Netscape 4.x 是使用 Symantec 的JVM , IE 4/5 是用 Microsoft 的 JVM , 而 Netscape 6.x 則是使用 JDK 1.3 的 JVM ,如果再加上 Sun寫的 Java plug-in ,那平台的複雜度 ,不比微軟的 Win32 少 .
Sun雖然宣稱 Java 程式可以寫一次 ,到處執行(WRITE ONCE , RUN EVERWHERE) ,可是事實上並沒有那麼美好 ,我覺得寫一次 ,到處調整(WRITE ONCE , TUNE EVERWHERE) 比較類似現在的 Java Applet執行情形 .
當你遇到這個程式在某些平台會跑錯的時候 ,一種簡單的解決方式是靠著教導使用者使用不同版本的程式 ,( 在瀏覽器時 ,可以透過 JavaScript/VBScript來偵測 ,並自動選擇版本) .
我自己則以一種簡單的方式來處理這部份的情形 ,我通常會在程式一開始 ,測試這些不太相容的功能 ,了解使用者的環境支援那一種方法 ,之後程式在真正執行時 ,就依一開始偵測的參數 ,再進行正確的處理程序 .
當你開始要操作繪圖介面 ,你會發現每個系統要學的東西可能就不一樣 ,Unix 下可能會用 Xlib , Win32 下可能會用 Win32 SDK ,DirectX , MacOS 可能又有新的一套 .但是這部份通常不會認為太複雜 ,因為沒有這部份的底層都得用不同的驅動方式 .
但是比較麻煩的大概是同樣一個檔在不同的平台間會有不同的表現, 以 Java Applet 而言 ,如果當你設計 Java 程式時 ,你會發現 Netscape 4.x 是使用 Symantec 的JVM , IE 4/5 是用 Microsoft 的 JVM , 而 Netscape 6.x 則是使用 JDK 1.3 的 JVM ,如果再加上 Sun寫的 Java plug-in ,那平台的複雜度 ,不比微軟的 Win32 少 .
Sun雖然宣稱 Java 程式可以寫一次 ,到處執行(WRITE ONCE , RUN EVERWHERE) ,可是事實上並沒有那麼美好 ,我覺得寫一次 ,到處調整(WRITE ONCE , TUNE EVERWHERE) 比較類似現在的 Java Applet執行情形 .
當你遇到這個程式在某些平台會跑錯的時候 ,一種簡單的解決方式是靠著教導使用者使用不同版本的程式 ,( 在瀏覽器時 ,可以透過 JavaScript/VBScript來偵測 ,並自動選擇版本) .
我自己則以一種簡單的方式來處理這部份的情形 ,我通常會在程式一開始 ,測試這些不太相容的功能 ,了解使用者的環境支援那一種方法 ,之後程式在真正執行時 ,就依一開始偵測的參數 ,再進行正確的處理程序 .
新手：
寫程式的第一步-解決問題
對於常常在變換開發工具的我來說 ,我一般都是這麼建議初學者如何去挑選書籍的 ,到書店去買一本該語言的入門書 ,再加上一本該語言的函式庫手冊(O’Reilly 的in a nutshell 系列算是不錯 ,可是不是所有程式語言都有出),先看看入門書籍對該語言的語法及如何去設計 ,再將函式庫手冊大致上快速瀏覽一遍 ,了解該語言大概可以支援什麼功能 ,再依自己的需求開始設計練習程式 ,當真正開始撰寫專題或專案的程式時 ,如果遇到沒辦法解決的問題 ,就查查所附的說明文件檔 ,如果牽涉的層面比較難 , 大部份的書籍都沒有提到時 ,那可以抽個空到書店去翻一些比較深入的書 ,譬如 ABCD Unleashed 之類的書(此處的ABCD 指該程式語言),如果這樣還是查不到資料 ,那就開始上網找資料了 ,你可以到該程式開發的網站找資料 ,或是到新聞群組(NEWS) ,電子佈告欄(BBS),去翻常用問題集(FAQ),如果你的問題蠻常見的 ,通常就會出現了 ,否則就試著去寫封信問問吧 :) 搜尋引擎大概是最後的選擇 ,因為通常這種問題很難從滿山遍野的網頁中找到答案 .
寫程式的第二步-深入研究
在學習程式設計的路上 ,其實學久了 ,你就會發現其實這麼多的程式語言的功能大致上差異不大 ,所以我會建議當你開始學習程式設計時 ,不要什麼都想學 ,VB/Delphi/Java挑一個當作起點 (我個人偏好 Delphi ), 把他所有的功能如檔案讀/寫,連結資料庫 ,繪圖 ,印表等 ,作個全盤的了解 ,那應該對你的程式設計功力應該有所提升 ,慢慢可以去唸點資料結構 ,演算法的書 ,這些東西幾乎對所有的程式設計師來說 ,都是必須的 ,等你熟悉後 , 可以看點網路 ,主從式資料庫 ,或多媒體的書籍 ,來充實這部份的知識 .
對於常常在變換開發工具的我來說 ,我一般都是這麼建議初學者如何去挑選書籍的 ,到書店去買一本該語言的入門書 ,再加上一本該語言的函式庫手冊(O’Reilly 的in a nutshell 系列算是不錯 ,可是不是所有程式語言都有出),先看看入門書籍對該語言的語法及如何去設計 ,再將函式庫手冊大致上快速瀏覽一遍 ,了解該語言大概可以支援什麼功能 ,再依自己的需求開始設計練習程式 ,當真正開始撰寫專題或專案的程式時 ,如果遇到沒辦法解決的問題 ,就查查所附的說明文件檔 ,如果牽涉的層面比較難 , 大部份的書籍都沒有提到時 ,那可以抽個空到書店去翻一些比較深入的書 ,譬如 ABCD Unleashed 之類的書(此處的ABCD 指該程式語言),如果這樣還是查不到資料 ,那就開始上網找資料了 ,你可以到該程式開發的網站找資料 ,或是到新聞群組(NEWS) ,電子佈告欄(BBS),去翻常用問題集(FAQ),如果你的問題蠻常見的 ,通常就會出現了 ,否則就試著去寫封信問問吧 :) 搜尋引擎大概是最後的選擇 ,因為通常這種問題很難從滿山遍野的網頁中找到答案 .
寫程式的第二步-深入研究
在學習程式設計的路上 ,其實學久了 ,你就會發現其實這麼多的程式語言的功能大致上差異不大 ,所以我會建議當你開始學習程式設計時 ,不要什麼都想學 ,VB/Delphi/Java挑一個當作起點 (我個人偏好 Delphi ), 把他所有的功能如檔案讀/寫,連結資料庫 ,繪圖 ,印表等 ,作個全盤的了解 ,那應該對你的程式設計功力應該有所提升 ,慢慢可以去唸點資料結構 ,演算法的書 ,這些東西幾乎對所有的程式設計師來說 ,都是必須的 ,等你熟悉後 , 可以看點網路 ,主從式資料庫 ,或多媒體的書籍 ,來充實這部份的知識 .
全站熱搜
留言列表
