Software Cinema

正在看一篇跟 Code Readability 相關的 Paper, 不知怎忽然想起大一剛進成大電機時, 學 Programming 的作業...

當然, 當時我學 Programming 與其說是上計概課學的, 不如說是自己學 + 認識的資工學長作榜樣居多, 但是書本上的練習跟上課的練習還是有差, 特別是你不想端出去的作業比別人差, 而且我們的計概課也不是一般呼嚨用的計概課.

我印象深刻的是一個 Hanoi Tower 的作業. 說到 Hanoi Tower, 其實我國中的時候就用數學的角度解過這個問題了, 但是寫程式是另外一回事. 稍微熟悉的人應該都知道, Hanoi Tower 是練習 Recursion 的基本入門題之一. 但是該作業有趣的是, 附帶了一個額外的加分題: 請用 Non-Recursive 的方式寫出解 Hanoi Tower 的程式 (當然, 要 step-by-step 輸出).

* 其實這題目有些書在 Recursive 章節後面也會加. 只是小大一是不會主動去看後面的練習作業題的 XD


那時候其實還不太會用 Search Engine, 而且 Google 在台灣也還沒有知名度, 很"傻"地就一頭鑽下去想解法, 以及怎樣寫成 Program, 還附帶要寫成 Document.

最後當然是有寫出來 ( 還上台介紹 = = 我大學生涯中第一次上台 ), 利用某些規律可以知道在三個 Towers 處在特定的 State 時, 就應該怎樣做 Transition 來到達下一個 State, 並且達到 Optimization. 也當然啦, 當時小大一是不會知道其實我在畫 State Transition Diagram 的 XD

其實在寫成 Program 以前, 我在找規律以及推導的過程, 本身就是 Programming 最重要的邏輯觀念之一. 可以在憑空找以及運算這些邏輯之中得到樂趣, 是後來可以成為一個積極的 Programmer 最重要的條件之一.

後來的作業印象中就比較偏向 Application 導向, 例如寫簡單的火車訂票系統之類的. 雖然其中也有很重要且複雜的 Scheduling 問題存在, 但是因為整個系統要考慮的 Functions 變多, 反而重要的 Scheduling 問題對於當時只是程式初學者的人來說, 變得不是那麼重要與有趣.

直到現在, 可能因為我們 Lab. 的大家習慣以系統角度通盤思考事情, 因此也反映到出給學生的作業上. 現在的作業寫滿整整兩頁 A4 的說明是基本 ( 一次作業一題而已歐 ), 前兩年甚至出現了高達六頁的說明 ( 印象中, 一樣是一次作業而已 ). 而看這作業說明的學生, 大多只是剛上大學, 剛要開始認真接觸 Programming 而已...

我們不禁應該思考, 這樣的作業美其名可以讓學生提早從整個系統角度思考 Programming, 可以更加貼近真實生活中的應用系統, 但是效果真的有比當初的 Hanoi Tower 好嗎 ? 如果我們並不期許計概課裡的所有學生最後都是一個好的 Software Engineer, 或是都要走 Pure CS 路線, 或許多些 Hanoi Tower 的題目能更引起學生自發的思考, 也更加容易傳遞 Programming 課程每次的教學重點.