如何寫出有用的程式？

原文 2010-02-16 23:59:23 節錄於舊精讚，告知原作者並重貼

所以，為什麼大學沒辦法教會你寫有用的程式?

程式作業生命週期太短

在資工系的大學生寫的程式，通常都是寫完交完就算了的程式，在這種情況下寫出來的程式，都是寫完丟就算了，程式的生命週期在交上作業的那一瞬間就結束了，相較於我自己寫的遊戲，我不停地重新檢視自己的程式，差別就在於，一個程式如果一直改，它設計不良的地方就可以被看得出來，好的程式設計應該是要經得起修改，但是大學因為作業交完就算了，可能再也沒有人會再看它第二眼，所以寫出來的程式常常都是硬寫出來的，規劃、維護什麼的都不需要，但是在現實世界中，程式其實是寫完那一刻它的生命週期才正要開始，寫完了程式，交到客戶手裡，客戶發現bug、或是有新的需求，這時再改程式，初而復始，直到程式不再被使用，程式的生命週期才正式結束，學校和現實的落差就在這裡，程式作業的超短生命週期讓它寫作的風格、設計都不受到重視，反正能交能跑就好，所以學生往往在遇到真實的程式會用寫作業的方法寫，下場當然是很慘

程式的規模太小

除了生命周期短，規模小也是另一個原因，通常作業都是幾百行甚至幾十行可以打發的程式，然而在真實世界中，程式往往是用萬行在算的，像我寫的遊戲就有上萬行的程式、甚至上十萬，而且還是好幾個程式，Server、Client、地圖編輯器等等，程式小，不經規劃和設計，硬寫也一樣可以寫出來，但是當程式一大，不經過適當的規劃、分析、與設計，下場就會很慘，那重寫無數次的遊戲只是例子之一，我曾經接過一個Case，錯估了程式的複雜程度，打算隨便寫就可以寫出來，後來發現複雜程度預估錯誤，所以加上了之前沒想到的部份，結果就非常慘，程式改這裡，那裡會跑出bug，而且你無法確定，這個bug到底是誰的，是什麼東西引起的，因為設計不良，疊床架屋，一堆模組之間有亂七八糟纏在一起的關係，造成一點點修改就牽一髮動全身，整個程式陷入無限的debug迴圈中，我發現這樣子下去不行，程式肯定寫不出來，所以就整個砍掉重寫，讓他們之間的關係，也就是藕合度降到最低，這才順利將程式寫出來，因為每個模組和其它程式的關聯都很少，所以可以很輕易地確定這個模組是正確的，而且關係少了，出了bug誰和這模組有關，也很容易找出來，這些經驗都是要程式大到一定規模才能會遇到的，在大學的作業通常規模都太小，學生自然不懂得設計，小程式硬寫也寫出來，何來的設計，而就算是畢業專題，通常也是寫完就算了，就算稍大一點硬寫也一樣寫出來，所以沒有實務經驗是理所當然的

但是我有遇過有門課教授出程式作業的方式我相當認同，而且可以改善以上兩點問題，他的作業一開始是簡單的功能，然後後面出的作業都是要求原本的功能加上另外的功能，如此一來，越到後來的作業規模會越大，程式也經過一再的檢驗，學生在這過程中可以學到程式如何重復利用，如果學生用硬寫的方式，很快就會吃到我上面所說的苦頭，越到後來程式越來越大，硬寫的程式以前的程式難以擴充，除錯也困難，生命週期長了，學生也能從中學到寫出較容易維護的方式，就算不知道，在以後看見了設計相關的概念，就會突然發現原來設計就是這麼一回事，在此我個人建議資工大學的課程，可以考慮用這樣的方式，設計每次增加一個小要求的大程式，如此一來可以解決上面提到的問題

寫的程式太少

不止是生命週期和規模的問題，以資工四年的程式作業來看，如果學生寫的程式就只有作業真的是太少了，個人其實也不是很喜歡寫作業，因為不是很有趣，並不是因為太簡單，難度不是問題，而是因為你覺得有沒有興趣，如果你對會計有興趣，或許可以自己寫一個財務報表的計算程式，如果你對物理有興趣，或許可以寫個簡單的物理模擬程式，如果你對數學有興趣，或許你可以寫一個尋找超大質數或計算圓周率的程式，如果你對遊戲有興趣，就寫遊戲，其實有太多程式都不難，而且都很有趣，像是鍵盤記錄器，聽起來很神奇，其實就只是一個掛在windows下的hook攔劫keyboard event而已，而木馬其實也只是利用socket等連線，一個指令一個動作，你傳什麼給我，我就做什麼的程式而已，有太多有趣的程式都比作業好玩，而實際上又會用到，如果學生只單純的寫作業，可能什麼是Win32API永遠都不會用，而Open source的library又要怎麼樣用，學校通常也不會教你，debugger怎麼用? 也很少有人會教你，資料怎麼找? 也沒人會教你，文件怎麼看? 沒人教你，所以除了程式的作業以外，學會如何寫有用程式的不二法門就是多寫，沒有人規定你要寫什麼好，對什麼有興趣就寫什麼，在這個過程中你找資料、問問題、解決的每個問題，都是你學到的經驗，而且課堂上通常都不會教你

請點擊下面原文連結：

相關連結

http://blog.ez2learn.com/2009/06/27/how-to-write-useful-program/