TCSE 2011 Panel discussion
前言
今年在輔大舉行的TCSE Panel discussion，三位與談者與眾多與會者對『軟體核心能力』這個議題，在一個小時的時間內做了許多探討。以下的抄本，由輔仁大學范姜永益教授轉錄自當天的錄音，特此致謝；抄本業經與談人修訂、補充。建議讀者參考當天的 投影片 一起閱讀，更歡迎大家在『輕鬆談軟工』一起加入討論。附帶說明，此抄本已略去錄音效果不佳的部份，敬請包涵。
Transcript begins
北科大 鄭教授開場
軟體領域最近的熱度，大家都知道。最近參加的一個會議裡，電腦公會的代表提到，幾家ICT大廠有數千個android 軟體開發的職缺；同一個會議中亦談到雲端軟體開發，在座好幾個大廠每家亦以數以百計的數量開出軟體開發人員的需求。各位，如果您或是您的學生會寫Android的程式 我想出路應該是沒有什麼問題。但是，身為教育界的一分子，我們要回頭問問我們自己：剛自學校畢業的軟體工程師寫的軟體到底如何？我們學生要具備怎麼樣的核心能力才能做出好的軟體？ 針對這個議題，軟工學會理事長李允中教授特別為今天的panel discussion訂了一個討論題目：『軟體核心能力』（software core competences）。針對這個議題，六月份時李教授在中央大學召開一個會議。李教授提出的核心能力分為基礎與進階：基礎的部份包含了基礎技術能力與團隊合作，像是如何描述一個問題、如何做設計、如何規劃Architecture 等等；進階的能力部分則涵蓋如何開發、審查、驗證 以及可用性、大型軟體的議題等的議題等。當然，我們今天的討論並不需要侷限在這幾個議題上，而可以有更深、更廣的的討論。
今天很高興我們請到三位軟工界非常熟悉的學者與談。第一位是中央大學的黃為德教授，第二位是銘傳大學的劉龍龍教授，第三位是大同大學的郭譽申教授。三位panelists 各有七分鐘的時間闡述見解共計二十一分鐘。接下來我們會留大約一半的時間進行討論，在座的各位可以在panelists 談完他們的看法之後，大家來討論。
中央大學 黃教授
大家袋子裡面是不是有一台手機，如果手機裡面沒有軟體，你的手機可能無用武之地，你到銀行要領錢，銀行告訴你說電腦壞了，可能是軟體系統故障或惡化(deterioration)，叫你兩小時後再來，你可能會抓狂，更嚴重的，假如是飛機，如果沒有軟體，它飛得上去下得來嗎? 這就是軟體之所以重要的小例子，可以說軟體的核心能力是無所不在的。軟體現在已經是推動人類文明的核心，所以我的想法就是說，假如今日人類賴以生活的各種設備裡沒有軟體，人類的文明與生活方式可能要倒退到十七、十八世紀以前沒有電腦時代的狀況。軟體是不可觸摸 (intangible)而且沒有重量的，但是可以左右許多設備的功能，甚至影響人類的生活與思維，所以其影響力到處存在而且不可或缺。那麼如何產生有用而且有影響力的軟體，這就要依賴優秀的軟體工程師來創造，可惜我們教育訓練出來的軟體工程師往往與社會的需要有一些間隙，這些間隙的產生大都來自於需求的不斷演變以及軟體複雜度的增加所致，而學生在學校所學往往無法應付這種變動，所幸目前出現一些軟體發展方法，例如「敏捷方法」(agile methods)，或「模式導向架構」(model-driven architecture簡稱MDA)等，或許可以解決部分這些問題，你可以在軟體工程學會的部落格(指輕鬆談軟工 http://sea-taiwan.blogspot.com/ )看到。現在就有一種現象，就是工業界與政府未能有系統地投資在軟體工業的建設上，至少不是很熱心，只是零星成立一些專案做研究發展，因此，我覺得只好先來改進學校的培訓方式，而且訓練出來的學生要有能力應付需求與複雜度的持續變動，這就是我們要探討的問題。我只談談培養軟體工程師的基本問題，原則上，諸如計概與軟工的課程必需重新設計，目前傳統的課程，大部份都是先訓練撰寫程式再教授模式(model)的觀念與製作，我認為這種訓練程序似乎有點「本末倒置」，而且無法培養學生具備處理高度複雜以及持續變動的軟體的能力，如果訓練的程序反過來，例如早一點講授如何利用UML的觀念與用法來建構模式，程式則依據模式來產生(可以使用人工或自動化)，如此一來學生將能在早期就具備分析與設計的能力，實際設計軟體系統時也懂得如何應用一些設計原則(design principles)與設計樣式(design patterns)，同時也比較能撰寫好而且容易保養的程式。我舉一則早期投在「輕鬆談軟工」部落格內的一篇文章：「好人難為」做參考，這篇文章敘述，一位專班的學生無法忍受他的主管因顧客的需求改變而要求他改變設計，因此十分懊惱無奈，我在意見信箱裡回應他，說需求的變動其實是稀鬆平常的事，我猜想這位專班學生可能在設計或撰寫程式時未遵循一些設計樣式或設計原則譬如Open-Closed Principle(OCP)之類，因此他的設計與撰寫的程式很難修改或延伸，如果我們的軟體工程師的訓練能先模式後程式，至少平行訓練，或許這位專班學生所碰到的困擾會降低許多。今天因時間關係無法說明太詳細，我不想討論一些比較「宏觀」(？)的問題，例如國際認證與國際化等問題(也許劉教授可以談談)，因為這些問題有些細節非三言兩語可說完，不過我認為如果我們的軟體工程師的能力只局限在寫程式，則奢談國際認證，也奢談建設軟體工業，因此「正確」培養優秀的軟體工程人員可能是當務之急，我認為先從課程改進做起或許比較實際，因此，如果諸位認為課程有必要改進，希望大家在軟工學會部落格上，針對：應「先學寫程式」或「先學寫模式」兩種教育訓練方式，先做一些討論。
(補充說明) 為支持上面所講的先模式後程式培訓方式的論點，我引用曾參與起草「敏捷宣言」(Agile Manifesto)的Stephen J. Mellor的說法：「Agile MDA(MDA + agility)是基於一種觀念：程式與可執行的模式(executable models)在運作上是相同的」，我個人認為，如果在MDA的程序中模式轉換成程式是自動化，則MDA就有助於敏捷軟體的發展，換言之，程式與模式就可說是一體的兩面，也幾乎可以說程式與模式是同意字，如果你同意Mellor這句話，或許可以考慮支援課程的改進 ─ 先模式後程式。
五分鐘淺談軟體核心能力
銘傳大學國際學院 劉龍龍
其實要用五分鐘來談軟體核心能力是不可能的事，以下就「與國際認證規範精神契合」、「團隊合作」、「可用性」等三個議題來切入。但是不管怎樣，如果有關軟體核心能力的討論只是止於程式設計(一般人很容易把重點放在這裡)而忽略了軟體工程其他85% 的涵蓋領域，那是有點悲觀的。
認證是目前台灣資訊就業市場所強調的一股力量，常常看到一些非研究型大學的學生取得多張證照的新聞；但這可能只是軟體相關認證業者的市場導向化行為而不是軟體核心能力的培養或鑑定的應有方式。如果把「認證證照價值>學位證書價值」與「國際認證價值>本土認證價值」當作訴求，而且大多的認證都是軟體產品認證而不是軟體核心能力認證，那台灣除了多替國外大型資訊公司賺錢之外對自己軟體產業發展的競爭力而言是沒什麼幫助的。在軟體核心能力部份，不妨參考IEEE-CS多年來持續推廣的CSDP/CSDA認證作法，包括它的考試資格、考試範圍(15 KAs, SWEBOK Guide V3)、以及軟體工程師應具備的資訊倫理等等。
團隊合作是在軟體開發過程中必備的觀念以及必定會發生的實際狀況，是軟體能夠順利交付的重要因素。雖然一般人都知道這一點，但是如果看下列三種團隊的規模：(一)4名學生、2個學期、交付10 KLOC(二)1500名專職人員、5年、交付15000 KLOC(三)開放原始碼Linux Kernel計畫、不知多少人參與貢獻、仍持續發展中；馬上就可以發現其中明顯差異性。台灣軟體從業人員在團隊成員的工作編組上通常也太簡單，連最基本的軟體開發者(需求、設計、建置、測試、維護等)、管理者(計畫、組態、品質等)、其他支援者(如文件、多媒體、資訊安全等)的人力配置比例都不很合理，負責人以為只要找到能寫程式的人就可以完成任務。事實上在軟體工程專業領域裡，「軟體」與「程式」是有很大差距的，軟體核心能力不是只有程式設計能力，而團隊合作因素或許是一個很好的參考點。
可用性是國際專業人士所公認的軟體品質最重要因素之一，因為如果使用者覺得某個軟體好用，那它就是好軟體。軟體產業中不同角色對於軟體可用性的看法是不同的；譬如軟體工程師可能會認為功能都正常就是很好用、美工設計師認為大地色系會讓眼睛舒服及心情輕鬆、而市場分析師或許會強調未來趨勢來導引使用方式。真正得使用者不太會去注意功能、色彩、創新等細節因素，他/她就是喜歡某個軟體。這個議題代表了軟體核心能力中超越技術與管理的那些部份，有許多一時還談不完的子議題如使用者介面(UI/GUI/ZUI)、人機介面(MMI/CHI)等等，再加上理論與實際(如軟體品質度量與軟體產品行銷)的考慮，應該都會是很好的參考。
大同大學 郭教授
Good design documents itself; bad design can hardly be documented.
大家好 我們準備進入正題 我主要講的是設計方面 那大概四年前 我開始重新寫程式 四年來寫的還不少 寫了一個Android application放在中華電信與遠傳上面 最近也寫了一點東西 剛剛放在Web上面 今天算是一點 經驗談 我覺的設計很重要 一般軟體工程也有很多重要的東西 不單純只是設計 軟體重要的也有維護 要容易維護則要有好的說明文件 有時候會聽到這句話是說： 好的設計是很容易看的懂的 即使沒有什麼說明文件也很容易看的懂 壞的設計是很難說明解釋的 我自己的經驗也就是這樣 我跟我博士班畢業的同學合作 他做coding比較多 我做比較少 他畢業之後 我來看他的code 好的code真的很容易看懂 不好的code就算有說明文件 也是不容易看的懂
OOD versus Design Patterns
我們現在的軟體設計都是Object-Oriented 設計原理大致有兩方面：OOD和Design Patterns 它們的差別是什麼 我個人的感覺OOD是比較抽象一點 一般會說名詞可能就是代表一個class 但仍不夠具體 Design Patterns則比較具體 我個人覺的是比較有用 學習Design Patterns就是熟悉一些好的設計實例 就好像是要學寫詩的話 熟讀唐詩三百首自然就會寫詩了 而不是去了解寫詩的原則 多看Design Patterns就能區別好的設計和不好的設計
• Principles versus Practice
• Not Enough versus Overkill
• Test-Driven Development
真正做設計的時候才發現 很多原則不是沒有用 而是真的要用的時候 都要做一些調整 沒有一個是可以完全一樣的 而且其實設計都是會改的 一開始設計是這樣想 但後來會發現某些東西沒有想到因此會修改先前的設計 真正去做是最重要的 設計最見的問題是常常在設計的時候無法考慮到case到底有多複雜 沒辦法全部都想清楚 會不會想的太簡單有些case沒有注意到 沒有想到 但是也怕會想的太多 實際上卻沒有那麼複雜 我個人的設計經驗是覺的 沒有完全清楚的時候寧願朝簡單的方向設計而不要想得過多 有些況狀可以碰到再來擴充 而不是一開始就想的很多很多 如果發現你想的方向根本就是不對的 這樣子你會發現很多code都會白寫了 從這個角度來講我是贊成Test-Driven Development 也就是說能夠早點去測試 當然這個測試不是說你整個系統完成再測試 而是把部分系統完成後 一部分測試 很多時候測試才會發現是當初沒有考慮到的 這個是很常見的 早一點測試就有辦法早一點發現某一些沒有考慮到的問題 然後再去改這個設計 我想這就是我的一些經驗
• Challenging Real Projects
• Design as Art / Make Software Masterpiece
前面是說設計 怎樣才能成為一個好的軟體設計師和開發者 我覺得實務是很重要的 好的設計師是由有挑戰性的真正的project磨練出來的 我說的project是真正做出來 而且可以用的 很多東西想的時候是這樣想 但是考慮到最後的使用常常發現有些case沒有考慮到 個人心態的話 軟體設計要想成一個藝術 把自己做的software想成是一個藝術傑作 這樣你設計就會越來越好
Market / Usability
Go International
當然除了設計以外 你還要考慮到一些市場 可用性這一類的 因為時間的關係 我就少講一點 software這東西其實是世界性的 我個人感覺台灣跟美國與一些先進國家差別很明顯的就是 我們在web上看到太少我們的software 而我們一些常用的software都是美國他們做出來的 未來我在退休以前 希望做一些software放在網路上 可以讓大家用用看
Workshop on Advanced and Usable Software, Taipei, Dec. 23, 2011
最後基於我剛剛講的理念 我在辦一個研討會 歡迎大家上我們這個網站來看一下 也歡迎投稿 這個研討會比較特別的是它是比較強調software 而不單單只是paper 如果你的論文已經投在這次的研討會上 其實很簡單 只要改一下強調你的software的可用性就可以了 歡迎投到我這個會來 我想我就講到這邊 謝謝
Q&A與討論
北科大 陳偉凱教授：
這幾年教書，對於軟體工程的議題接觸越來越多，我自己的感覺是這樣的：我們有許多課程教學生寫code，而且code也寫的很多，但是，能動的code並不一定很漂亮，舉例說，變數稱亂命名就是很不好的，因此，code不是能動就好了。最近幾年我開始嘗試除了要求學生寫出code以外，還要再看code寫的漂不漂亮，把學生寫的code交給助教審查，將「code是否漂亮」也列入評分，像這樣的議題，不知道Panelist或在座的先進有沒有經驗或作法，我想聽看看大家的想法。
大同大學 郭教授：
因為我是自已寫code我對這方面最有感覺 我這麼老才重新寫程式 我非常清楚 我沒有我的學生 或是我的小孩 (我的小孩也剛好是資工系)那麼熟練快速 我打程式都是一個手指在打 說實在我不是很擅長 但是我有自信我寫出來的software 的品質軟體不是寫的快寫的多就好 當我看我學生寫的程式 我就會發現 他確實比我熟練他寫的出很多的code出來 但是這樣子的code 修改起來是非常痛苦的 所以寫程式的關念是非常重要的 怎樣的程式是好的 就好像是很漂亮的唐詩三百首 你詩讀多了就自然能區別怎麼會是好的 這很難講 其實我也沒辦法做到說 第一次設計就可以做的很好 我可以感覺出來哪些地方不夠好 我會慢慢去做修正 這個其實也是一種經驗你必需要多做 我想 對很多同學來講 我有一個很好的推薦就是不要忍受不好的程式 為什麼二十年沒寫程式 還敢再來寫程式 其實在於我當學生的時候我就不能忍受 設計得不好的程式開始 交作業會有個期限 但是交的時候我會想一下哪裡地方還不夠好 作業已經交了但是我還是會自己把程式改好 實際上如果你想清楚 在改的時候 不會花你多少功夫 但是改完之後 你會覺的自己程式漂亮了不少 自己就會很開心 如果有這種習慣的話 相信你的程式就可以越做越好 有時候沒有特別訣竅 這有點像藝術家 你會希望你的作品是好的
北科大 鄭教授：
不過在執行這種課程的技術上，請問一下有沒有什麼見解或是想法？或是陳老師可以分享一些經驗？
北科大陳偉凱教授：
我的辦法不是很高明，基本上就是「坳」助教，要求助教看過所有的code，並且評分，當然這樣做是非常耗時間的。在評分方面，我是用程式裡的壞味道來當做標準，我做了一些統計，觀察學生作業中壞味道的數量，我發現在連續性的作業中，如果持續要求學生去除壞味道，壞味道的比例確實會減少。當然這是只一個我目前使用的辦法，我自已也還在實驗中。
來自中正大學的與會者
我以前程式寫的時候都是我在想到什麼就寫什麼 但是一段時間過去之後 我會發現不知道我寫了什麼 但是在老師開物件導向的軟體工程課 老師通常會要求先想到要作什麼 最好要用UML的工具 先做需求分析 到時候用? 了解會有哪些物件在裡面 屬性 加上我們的project 之後 通常code部分老師都不會去在意我們如何做 通常只會注意到我們做到什麼程度 雖然回頭來看會看不懂自己在寫什麼 但是我們會知道我當時在做什麼 就算是code當時消失了 我也能夠通過印象再次寫出來 相信在座的各位寫code的能力都是很強的 這是我這一、二年來 的一個經驗 一個心得
中央大學 黃教授
大家回憶一下，整個發展軟體的過程就是不斷提升發展方法的「抽象層次」 (level of abstraction)，當然code是扮演很重要的角色，但是為什麼不去想想，model可以轉換成code (人工或自動化)，這就是OMG提出MDA方法的基本想法之一 (雖然不是唯一)， 為什麼你一定要去寫code， 為什麼你不去寫model？寫model的話會有許多好處，例如容易去修改產生的軟體，也容易應付軟體在各種不同平台環境的執行，雖然用UML做出model執行不是百分之百，但是也非常接近了，依照國外公司的經驗，如果使用MDA工具，model可以自動化轉換成約85%的程式，發展時間大概可以省30%以上，那為什麼人一定要一行一行去寫code? 是否使用一些工具，如MDA工具，把model轉成code是可以討論的議題。大一開始學習發展軟體，為什麼不早點教他/她們使用model來思考或表示軟體的內容與結構，再據此來撰寫程式？這種訓練觀念，將會影響學生未來可以使用高抽象層次的方法來發展軟體，例如懂得使用設計樣式或設計原理發展軟體，影響所及所發展的軟體容易保養，也容易展延。我教了好多年OOSE課程，在我編寫的講義資料裡面，特別有一章就是在說明如何構成model以及其如何變成軟體系統。
銘傳大學 劉教授
其實我覺得 model 與 code 不是對抗的，因為現在的 code 已經都是很 high level 的了，譬如說以前做一個 user interface 必須做很多零碎的事情才能夠完成，現在只要兩三下就能完成，所以我想 code 與 model 並沒有那麼大的差別。 為什麼 Java library 現在會大得不得了？因為它把好多好多屬於 model 的東西都建好在 裡面了。當然大家都希望能把 code 建成比較好用的 model，而這也比二、三十年前寫 code 要快樂多了，我們當初寫 code 都要從最基本的組件如 linked list 等開始寫，現在都不用了，有許多 tool 來幫助我；所以現在我一個人做個半年、一年就可能做些東西出來了，但是早期絕對不可能這樣做，你非要有一個 team 才能達成。現在像是在 eclipse 下寫 Java code 時，裡面已經有許多東西的架構就已經像是 model 一樣，而若能簡單地用 model 當然你打的 code 就會少很多，除非是一些比要細節的處理，那就沒有辦法。所以我覺得二者都是必須的，這不是對抗。
Transcript ends
註：本文作者為鄭有進教授，由本人代為上傳
我是那位被坳的助教，在看了四年共五個學期無數學生的程式碼後，會發現只有少數的學生一開始(例如第一次作業)會把程式寫好，多數的學生都是在被要求甚至會被扣分的壓力下，慢慢地才願意把程式寫漂亮一點，問題是，他們真的養成習慣了嗎？體驗到寫出好修改的程式的重要性及帶來的好處嗎？我個人是打一個大大的問號。雖然沒經過任何證實，但如果突然在期末的最後一次作業，當學生在為了多門課的作業及考試奮鬥時，不要求程式品質也不會因為程式寫不好而扣分，我想不會有太多學生在寫『新的程式』花太多心思在寫得漂不漂亮上(OS：也許老師可以坳今年的助教實驗看看)。
回覆刪除其實我不認為有什麼像『九陰真經』或『易筋經』武功秘訣般的，一教就能打通任督二脈然後馬上就能夠寫出好軟體的『軟體核心能力』，問題是在於有沒有心想寫出好的軟體，偏偏『心』這種東西是很難用教的。先前參加OpenFoundry的一個小型聚餐，與會中不少人都投入在Open Source的軟體開發上，但其中很多人都不是科班出身的，我不知道他們的程式寫得好不好，不過有些固定被OpenFoundry邀請為講師，在蠻多地方教授程式相關課程，我想他們的能力是被肯定的，有趣的是他們的能力不是來自科班學校的教育，但他們有寫程式的熱誠，也很想把程式寫好，自然而然會努力學習所需要的能力。
過去幾年帶學弟妹做國科會的整合型計畫(參閱輕鬆談軟工先前文章)，只要我站在學弟妹後面或是坐在他們旁邊，他們總是很緊張，因為我會對他們寫的程式頻繁地碎碎唸，像是複製貼上被我看到、變數的命名不好、縮排不對、註解沒寫、function的內容太長等等，雖然這都是很基本的coding standard的小毛病還談不上設計好壞，但我就是很堅持我想看到的程式碼就是要這樣乾淨易懂。經過一段時間，他們習慣了，也開始覺得這樣不錯，雖然程式的設計上沒有非常漂亮，但至少容易看懂，自然也就好維護。如果連這些芝麻綠豆大的小事都做不到，我不認為那個人會想把軟體寫好。
有人說學英文需要環境，不管是出國或是想辦法讓自己多接觸英文的事物都行，如果學生想把軟體寫好的熱誠不夠，那想讓學生學好軟體核心能力，學校也許可以提供一個環境：讓學生打從內心認同(多麼痛的領悟)唯有把軟體寫好才能繼續玩下去的環境，例如：把project的規模變大(10~20 kLOC以上)，執行的時間變長(2~3個學期，跨課程但project是延續的)，且需求會隨時間改變，讓學生非得以團體的方式開發軟體並修改既有的程式，更重要的是需要花時間讓學生知道什麼是好的什麼是壞的設計(將code quality納入評分並給予設計上的評語，並用peer code review的方式讓學生看好跟壞的設計)，或許這會讓許多學生恨死了，讓老師和助教累翻了，如果能讓學生覺悟，也是不錯的結果。
如果真要說什麼能力是重要的，我覺得是abstraction的能力(諺語Q35)，或稱作modeling的能力，但我用abstraction這個字眼，是不想跟特定工具、語言或是開發方法綁在一起，例如MDA、design pattern或是OOP (OOAD)，以OOP為例，用物件應該可以開發所有的軟體，但不一定是最適合的一種方法，在一些條件限制下，更早之前的procedure based的方法或是直接用MDA工具將model轉程式會是更好的選擇。課程怎麼安排，我覺得是其次，很多作業以結果定勝負(打成績)，學生是不會知道他作的abstraction好或不好，因此他只會想如何把功能做對，所以課程的設計應該是要讓學生透過指導搭配剛剛提到的環境，逐步地提升level of abstraction。
最後，我對於投影片中『工業界與社會的需求與學校教育訓練不吻合』，有另一種看法，即使教再多的design pattern或是軟體工程方法，到業界後，很多根本就沒有被採納，以這位高工時工程師的說法：http://www.mobile01.com/topicdetail.php?f=566&t=2370096
以及幾位已經進入產業的同學的說法和先前參訪xTC時號稱是軟體工程部主管的說法，遇上懂design pattern、CM、Requirement Management、PM或是Scrum的主管就已經算是運氣好了，既然這樣，台灣軟體界對人才的需求會不會根本脫離國外的腳步？讓軟體業朝向一個永遠都是高工時卻開發不出好軟體的產業？
在拜讀完各位教授對軟體教育的看法後，實在是令人感動。因此也想分享一下我自身的學習經驗，希望能對台灣軟體教育有幫助，對於Model與Code的學習，我個人是從Code開始，由於自己從國中畢業即進入專科學校，因此整個5年的專科生涯，在寫Code上有很深的經驗與基礎，當然也吃了不少的苦頭，但是至今日為止，我很感謝自己那幾年的學習經歷，因為若不是因為吃過那幾年的苦頭，我可能不會在我專科畢業後，開始自修進入OOD與Design Pattern的世界，正式對形而上的Model產生興趣，甚至不知不覺地研究了十年有餘！
回覆刪除其實就我個人的經驗，我覺得Model與Code對於學生來說都很重要，但是其學習的先後順序應該是先Code再Model，而且依個人淺見，我認為未經超過3~5千行專案(獨立完成)洗禮的學生，直接進入Model的學習，就像是一個走在鋼索上的實驗，少數幾個人可以順利走向目標，這些人我們稱之為"天才"，但多數的人很可能會從鋼索掉下來，並且從此手斷腳斷產生陰影！
我遇過很多人，嘴上談了一口好的Design Pattern與MVC，但是寫出來的Code卻連Low Couple和High Cohesion都辦不到，這些往往都是太早接觸Model學習的人所易犯下的錯誤，究其原因多半是因為所學的形而上知識難以落實於軟體設計，因而始終無法讓形而上的知識轉而變成軟體實作的常識。
我很慶幸自己在專科時接觸了許多軟體設計的苦頭，那時後我很笨，老是把同一個專案的程式碼拿來改來改去，改了一個月功能還是不變，但是只有我自己清楚裡面到底改了什麼，別的同學笑我無聊，但是對當時的我來說，只有我知道我的程式是拿來玩的，而且只有我知道我玩出了什麼心得。專科畢業後，偶然接觸Design Pattern的書，刺激我開始自修的動機，竟是於當時我完全能夠體會那些Pettern要解決的問題所帶來的痛苦，所以在我之後的學生生涯裡，我一直都把Design Pattern當成是一本奇書，一本幾十年前的人寫出來但是現代卻很多人不懂珍惜的書。
另一段故事想分享的是，因為我專科學的是電子，接觸工數比同年的高中生要早好幾年，但是工數在我專三就被我自己列入放棄名單了，原因並不是我學不會(個人數學其實還不差)，而是在於當年的我不了解學工數的意義，但是這個決定卻在多年後讓我自己感到後悔，因為多年後我才驚覺許多技術都或多或少都會聯結到當年的工數底子，而這門學科在我年輕時就被我丟棄了，而且在我丟棄後，等同於通訊，電磁，DSP等也一併丟棄，而在我了解到事情嚴重時，已經來不及了。
有鑑於此，我覺得學生應該先從Code開始，再經專案的琢磨，爾後作形而上的訓練，或許是比較符合"人"的教育方向。以上多半是以我個人的經驗，並不能代表全部人，在此僅做分享，或許學生本身也是一種極端，主要還是希望能夠讓大家多聽到一些故事，畢竟教育應該是從多種面向上尋求一個折衷，適合多數人的折衷。
如果說code與model不是對抗，我贊成，但如果說兩者差別不大，我有點意見，因為兩者的抽象層次不同：
回覆刪除抽象度
低------------------------------------------->高
Machine Assembly Procedure OO Modeling
language language language language language
如果code與model沒大區別，OMG似乎也不必發展MDA。
黃教授已點名兩次，不反應大概是不行的，雖然已經退出江湖了。(按：黃教授近三十年前就是我老板。)
回覆刪除我想舉兩個例子來看code與model，尤其是說給年輕的朋友們聽聽，也許更能感受一些東西。先看這個：
object code=compile(source code)
這是程式設計者習慣的函數式，而它也是具體的，不管是C#、Java、Python或是最新的語言，都是立即可用的軟體開發工具並搭配良好的整合環境。再看這個：
requirement spec=transform(requirement)
意思是說需求分析工作是把如天上一朵雲般的需求經由elicit以及conflict resolve的手段轉換成一份需求分析說明文件。光是這句解釋的話就夠抽象的了，更不要說去瞭解這個transform到底是如何達成目的的。
如果前者是code、後者是model；那兩者是完全不同的知識領域，甚至有人永遠無法體會程式設計的樂趣，也有人永遠無法享受有能力因應需求不斷改變的欣悅。
如果先不要管model而只從code技術不斷進步的角度來看，以前的組合語言指令、高階語言敘述句、函數式定義、邏輯式敘述等等程式設計方式，到物件的描述與例子(instance)引用、serializable應用，到現代的網路上resource、service等等；只要design pattern夠好、library reuse程度高、普及性強(意思就是不能太難，非軟工人都可馬上學會如何用而不必去修演算法及資料結構)，那它就會得到市場支持。至於如書上說的物件導向技術：繼承、多形、封裝等的完善程度，在code的立場並不是太重要，只要不斷有新產品推出就沒問題。當程式設計的工具及環境提供越來越先進時，很多model就是現成的東西，而code與model的差異就不大。譬如google提供的很多東西，包括Android的發展環境，就像是model driven，只是很多的transformation使用者不需要看到，最後有程式結果就行。
如果一定要從model開始，對於有經驗的朋友來說應該還OK；但是對於普羅大眾來說，也許會覺得抽象就是抽象，與程式設計是扯不上關係的。
謝謝劉教授的意見與反應，從中我也學了不少有關coding的知識，如果我們能夠建造軟工部落格成為討論軟工意見的平台，則軟工學會設立這個部落格就達到目的，希望大家加油。
回覆刪除我之主張code與model的區別，model是指visual model，從agile MDA的角度來看，model相當程式，撰寫程式就是撰寫model，Code與所謂executable model作業上是相當的(Stephen J. Mellor)，我覺得如果不撰寫"visual" model(通常是使用UML)，則程式創造很難與agility連結，不知對不對，對我來說，劉教授舉的例子仍然是一種程式（看法也許不對因為我對撰寫程式並不內行），因為我說的是寫visual model。至於教學時寫model與寫code何者為先，見仁見智，或可討論。
TCSE 2011 Panel Discussion的意見欄內並未顯示劉教授10/15的意見，只以email方式傳遞給各位，不知何故，有請薛教授查一下，謝謝。
回覆刪除話說，劉教授提到程式設計不會超過軟體發展的15%，其他85%不知指甚麼，我想這85%應屬「分析與設計」，這個分析與設計是在建造相關的model，Ivar Jacobson在他的UP提到：「軟體工程的核心是建造一些模式的流程，從抽象到具體(concrete)」，如果我們能接受Jacobson的說法，我想我們的軟工訓練就能重視model的建造技術，我們的學生或軟體工程師也許不會陷在15%的「泥沼」。
Harrah's Cherokee Casino & Hotel Map & Floor Plans - Mapyro
回覆刪除Harrah's Cherokee Casino & 익산 출장안마 Hotel features 대구광역 출장마사지 hotel, dining and live entertainment. 포천 출장안마 Find your way around the casino, find where everything 춘천 출장마사지 is 서산 출장안마 located with