王小明5106 wrote:
同感.其實程式設計師...sambad 兄, 不好意思. 有點意見和你不同.
Delphi 雖然也是 OOP, 但是我個人覺得它把物件包裹的太好, 雖然入門容易, 深入卻很難.
(恕刪)
小明, 我沒寫過delphi只寫過Pascal, 也沒提過delphi. 不過, 只要能真的搞懂delphi, 那東西拿來發展一些商用套裝軟體是很不錯的. 印象中以前網路看盤有個叫什麼小精靈還是點金靈的即是用delphi所寫, 光那個創意就幫那家公司撈了許多錢. 不過, 目前流行的任何一樣程式語言, 幾乎都是入門容易深入卻很難. 但有時能否賺錢倒不是靠程式難不難, 反倒是靠創意居多. 舉個有趣的例子, Wii功能沒PS3/XBOX360強大, 賣的卻比功能更強大的遊戲機好, 靠的即是創意二字.
關於Jack兄所提程式測試問題, 這個分兩個部份. 第一個是程式員的測試, 這東西和邏輯有關, 但是經驗佔大部份. 尤其是不同的程式語言有不同的特性, 出錯的地方也不大一樣. 想要把debug弄好, 看高手debug最快, 但也要自己爭氣, 有著不服輸的精神, 堅毅的把自己的bug都抓出來, 久了自然就變成行家. 第二個則是公司的debug策略. 除了程式員的測試外, 有規模的公司多半有一定的除錯程序, 會將程式員寫好的程式交給另一批專業的測試人員來找尋錯誤. 然而, 找出來的錯誤照樣要由程式員來debug. 針對大型的系統來說, debug所花的時間往往超過最初寫程式的時間, 但某些超級程式員就是debug厲害, 所以別人花一天debug還抓不出來, 他只要花個幾分鐘就搞定, 這種人當然工作績效就比其它人高囉. 不過, 程式測試這東西多半在學校老師能教的很有限, 要靠自己練習居多. 說真的, 我在職場上見過太多人debug一整天抓不到錯誤, 就是因為邏輯出了問題. 那些一兩天debug不出來的程式, 往往錯的只是一兩行程式碼, 真的會叫人哭笑不得. 當然, 這也是某些價碼高的程式員之所以能價碼高的原因之一(但往往不是主因). 一般寫程式的話, 依循結構化程式設計原則, 多半可以寫出一定水準的程式碼. 但很多人忽略副程式不應太長的原則, 很多人忽略反覆使用的程式片段應以副程式呈現的原則, 太多人忽略了一些"小節", 導致程式難以維護且除錯困難.
至於躲Oracle的Bug, 這個超級好玩, 連他們家的SQL最佳化也很有意思. 不過, PC版Oracle沒價值, 要就去玩大型電腦的Oracle, 光要把它管好(DBA), 月薪就比一般程式員多很多了. 話說回來, 每種不同的資料庫都有他們不同的"特性", 有時未必是Bug. 但我很同意, 每家的Bug都有一些, 如何閃掉與資料庫系統相依的Bug真的是學問. 偏偏這種學問並不共通, 而且又會隨著版本變化...ORZ
不過, 提這些事情都有點遠了. 想學寫程式沒什麼捷徑, 老老實實的每天練習, 最好寫一些自己真的要用的東西, 那你遲早會進步的. 此外, 我會建議英文要學好, 養成閱讀Help File的習慣. 微軟雖然很多人對他們家不滿, 但他們的Help File寫的真的不賴. 很多時候你不必買書, 光看Help File就足以讓你學到大部份書上沒教的事情. 此外, 英文好也容易幫助你猜測你要的功能是使用哪些屬性或方法. 最後一點, 我建議永遠保持好奇心, 多嘗試你在學習的程式語言裡面一些你沒用過的功能. 但是, 以上所提, 最好是英文程度好, 直接看原版的Help File, 真的可以讓你受益無窮.
此外, 我是誠心的要補充一點, 程式語言沒有好與不好的分別, 只有流行與否的差別. 不流行的程式, 日後有升級困難的缺點, 且使用與維護成本將變得較高. 同樣流行的程式語言, 又會因為要寫的程式目的不同, 應適當的使用不同的語言. 用C++系列的寫使用者界面絕對不是件好玩的事, 用VB.NET系列寫Driver也肯定不妙, 善用不同的程式語言來做不同的事情才是王道. 整個C系列的語言雖然擁有執行速度快, 彈性高, Portability強的優點, 但畢竟程式碼的後續維護性較差, 並不適宜做純MIS應用程式的撰寫. 針對科學計算, 則Fortan系列的運算速度實在是快, 往往比C系列的語言快一大截; 但C語言直接用in line assembly寫X87的組語副程式, 則運算速度比任何中高階語言快數百到數千倍之間. 所以, 千萬不要心存定見認為誰好誰壞, 看用途來採行最佳的程式語言才是較佳的方式.
