Re: [請益] 看懂微積分,就會寫程式???
※ 引述《ggg12345 (ggg)》之銘言:
: ※ 引述《ggg12345 (ggg)》之銘言:
: : 推 reader:電腦科學和軟體工程的知識 以及創新的能力 不就是專業嗎? 01/04 12:59
: 資訊xx是比較特別一點, 再假設資x各有重點, 各有特色. 假設 您選了
: 電腦科學 跟 軟體工程.
: 機械工程會選 物理跟數學的微分方程 當基礎, 甚至有其偏力學的工程數學
: (數學系認為那是應用數學)當主要的工具, 電腦程式跟數值分析 也是其工具.
: 電機工程系差不多, 只是偏所有電學磁學, 也有 Fourier, Laplace 這類工數.
: 這些工程類的課目都跟其主要工具密切相關, 都是在解決其專有的問題.
: 現在問題並非微積分這種工具管不管用? 而是這道具似乎對軟體工程幫不上
: 忙, 所以學的人會很惱火. 問題是怎沒有給個管用的分析道具?
: 問題變成 電腦科學提供那種 數學分析工具 給 軟體工程來用?
: 做軟體工程的用甚麼抽象簡化的道具符號 彼此溝通? 他們使用的都一致嗎?
我好像需要做一點軟體工程掃盲...
正如微積分不能處理所有問題,軟體工程也並不存在著單一解決方法。
但就實務而言,统一塑模語言 (UML, Unified Modeling Language) 算是
目前應用最為廣泛的軟體分析設計工具,以十四種相互關聯的圖式,
表達出軟體設計的各種面向的結構或流程。
雖然這是專屬於物件導向開發方法的工具,但已經很接近工業標準了,
想要跟國際接軌的軟體公司,大概都得全面使用。
就軟體領域的重要性而言,這顯然比微積分更值得成為必修課程,
很不幸的是,在大多數的資訊科系裡,學生們都學不到這個東西,
更別提熟悉了解並以此展示自身的專業性了。
少數學校應該有開相關的選修課程。
這東西算是非常基礎的工具了,到今天差不多有十五年的歷史,
以此作為分界,台灣的資訊科系大學生,可以說除了應用領域之外,
很難學到近十五年來的軟體工程和電腦科學發展。
相反的,電子電機的相關科系,卻不太會有這種現象,至少這種抱怨不常聽到,
某種程度而言,資工系彷彿就是給電機系打雜的程式工人,
所以有必要學一堆電機系認為幫他打雜的程式工人該會的東西...
單從這一點來看,就可以知道問題有多嚴重了。
: : → reader:這本來就是資訊方面的專業和其他只是會寫程式的人的不同 01/04 13:00
: : → reader:光是這個理所當然的專業能力 就需要大量的時間和精力了 01/04 13:02
: : → reader:不把這種核心專業搞好 卻貪圖其他的能力 就是捨本逐末了 01/04 13:03
: : → reader:例如學到會做 refactoring 的程度就不是那麼容易了 01/04 13:06
: : → reader:但這大約是 15 年前流行的東西... 跟上國際水準就是這麼難 01/04 13:08
: refactoring 顯然是需求, 目標.
: 電機, 電子, 機械, 土木工程的也都在幹這類事, 那類系的造出的產品也都強調
: 這種要求, 甚至分化有 工業工程, 生產管理, 製造工程 這種專業科系.
: 所以也要把 工業工程, 生產管理的道具也拿過來用? 譬如:線性規劃 這類道具
軟體重構 (refactoring) 是一種軟體開發技術,不是一個軟體開發需求或目標。
這方面的基礎研究、方法和工具有著區隔很大的發展。
就研究來說,這主要是理論電腦科學中的範疇論的應用範圍,
基本上是以群論為基礎的數學理論。另外一方面,編譯程式的最佳化研究,
也可以算是有高度相關的領域。
就方法而言,由於理論還不完備,來自於電腦科學支援相當有限,
編譯程式的實作方法,算是主要的知識來源,實務上需要大量的經驗累積和交流,
這和其他工程領域的狀況是類似的。
就工具來說,目前的主流是使用自動化工具,直接在軟體開發過程中調整,
後設的分析評估效果並不好,因為在每一個小地方仔細,大範圍的問題就會少很多。
至於比較傳統的演算法分析和軟體效能測量,則一般不在程式碼重構的討論範圍,
那又是另外的知識和工具使用了。
軟體開發過程一般不需要額外使用數學工具,直接使用電腦輔助工具才是正途,
即使其中有一些數學分析過程,也早就被包裝在軟體之內。
: : → reader:像微積分這種特定領域才需要的東西 重要程度沒有那麼高 01/04 13:11
: : → reader:而解決問題需要的領域知識 則是出社會後才比較需要再進修的 01/04 13:16
: : → reader:覺得數學工具不在學校裡先學好就永遠學不會 則是一種迷思 01/04 13:17
: : → jhchou:純好奇 現在有哪些學校有開軟體工程相關課程的 有人知道嗎 01/04 13:18
: : → reader:何況多數人在出社會的短時間內都走不到專業分析師的位置 01/04 13:18
: : → reader:還加上多數分析工作也不需要微積分 學術研究一樣用不太到 01/04 13:21
: : → reader:這樣子逼學生一定要花大量時間去學 其實是有檢討空間的事 01/04 13:22
: 因為微積分這個道具無補於 軟體工程, 個人也覺得強調它是個專業道具 確
: 實有問題. 但若要求解 最佳規劃 能懂微積分還是會好一點, 方法多一點.
: 資訊科學顯然跟數學是同屬 理學院 這種原理派別的. 既然分門立派, 那是
: 像物理對電機, 機械, 土木工程講原理的, 還是像應用數學那樣對這些工程
: 講道具解法的? 還是因為兩者都有, 還有一些不同的, 因此另成一派?
軟體工程重視的是一整套的方法論,強調的是運用一系列的方法和工具,
建立可長可久儘可能滿足最大範圍需求的軟體系統。
這其實是需要通過軟體開發者和軟體需求者之間的互動來達成的,
因此近年來軟體開發模式成為最主要的軟體工程方法,
所要追求的就是最佳最有效滿足需求的互動方法,
早就不再是過去那種以單一演算法的研發為核心,甚至只是問題求解的情況。
甚至可以說,從近五十年前軟體工程理論興起之後,軟體開發的目標就已經轉變了,
抱持著程式設計就是利用電腦的運算力做問題求解的想法,
其實完全不是資訊專業所需要處理的議題了,那是各領域的專業人員的事情。
現在的軟體開發,最終所追求的,就是一個完善的軟體架構,
能夠有足夠大的彈性和穩定性,面對各種需求的變化而能有效回應,
這個架構的本身很可能就需要大量的電腦科學知識和軟體工程實踐才能完成。
在實務上,完美的軟體架構跟完美的建築一樣,都是不存在的,
於是面對現有的問題做前瞻性的思考和設計,就是最主要的做法了,
而最接近的工程領域,也就是建築了。
: 疑問就是 資訊科學提供那些 原理, 道具 來協助解決 軟體程式 面臨的問題?
: 機械工程師顯然不是 車床這類工具機的 師父, 因為他要能分析機械面對的問
: 題, 解決問題.
: 程式設計師顯然也不是 電腦司機, 那麼他面對那些問題, 解決那類問題, 依靠
: 那種可以傳授學習的道具或方法?
: 工學院的建築系, 若是做大樓規劃設計, 建築造型的, 顯然不是只依賴物理原理
: 數學道具. 建築設計師通常在 藝術風景 素描畫圖上花費相當長的時間.
: 資訊XX 的原理, 道具, 展現 會是那些? 還是資x 只是龍套, 附尾?
這些問題很難回答,因為相關的知識非常多,根本沒辦法在四年學完的,
而每一種電腦科學和軟體工程的知識,都可能在某個時候有用。
若要實際論起重要性而言,微積分大概就是數值方法一門課的價值吧,
好好學 lambda-calculus 甚至會比學 calculus 有用得多,
因為對程式語言理論的學習深度不足,是現在資訊系學生的一個很大的問題,
對於程式語言的學習和程式設計的能力就很容易受限,
像這種基本問題不解決,卻要強調微積分這種解題工具,其實很奇怪。
如果說是工學院的共通課程也就算了,但一樣是數學,在電腦科學中,
比較有關的數學不學,卻要說學微積分比較有用,實在沒有太多道理。
電腦科學相關的數學非常多,把微積分相關的課程換成這些數學,
恐怕只有好處沒有壞處,把微積分當成數學代名詞,以為少學了微積分,
就少學到重要的數學理論,可以說完全是對電腦科學的認識不夠所致,
更不用說軟體工程相關理論和實踐,其實是更需要的課程。
對了,有些學校的軟體工程,只是軟體工人的管理,我說的可不是那種東西,
那是大約三十年前流行的觀點了,軟體工程應該是軟體開發人員的自我實踐,
而不是軟體工人的管理學。
※ 編輯: reader 來自: 218.174.32.145 (01/04 18:38)
推
01/04 18:45, , 1F
01/04 18:45, 1F
推
01/04 19:26, , 2F
01/04 19:26, 2F
推
01/04 19:39, , 3F
01/04 19:39, 3F
大多數資訊科系確實都很好混,如果不談有自學和熱忱的一些人,
學校教育出來的學生,無論就學理基礎還是工作能力,都非常有限。
或者說,現在資訊科系的基本學歷已經是碩士了,大學畢業的實力,
可以說問題很大。對於這一點,我還真不知道該怎麼評論。
但若以連同研究所合計六年的訓練來看,很多地方還是相當不足,
我很懷疑許多人的學習,就是補習班一年加研究所兩年...
總之,大部分的資訊科系畢業生,還真的只能做程式工人,
解決一些雜七雜八的問題,相對於其他工程科系畢業生的專業來說,
實在是有一點落差,而我想這不是一件好事。
其實微積分不難,其他該學的數學並不會比較簡單,
很多人學一點微積分就哇哇叫,學校似乎也把它當做基礎數學訓練,
這要怎麼說呢,通通都不太對,學一些更難但更有資訊相關性的數學,
好像才是比較對的做法。
推
01/04 19:39, , 4F
01/04 19:39, 4F
推
01/04 19:43, , 5F
01/04 19:43, 5F
※ 編輯: reader 來自: 218.174.32.145 (01/04 20:03)
推
01/04 22:01, , 6F
01/04 22:01, 6F
推
01/04 23:40, , 7F
01/04 23:40, 7F
推
01/05 00:01, , 8F
01/05 00:01, 8F
推
01/05 00:26, , 9F
01/05 00:26, 9F
推
01/05 00:50, , 10F
01/05 00:50, 10F
推
01/05 01:01, , 11F
01/05 01:01, 11F
推
01/05 01:24, , 12F
01/05 01:24, 12F
→
01/05 07:04, , 13F
01/05 07:04, 13F
推
01/05 21:10, , 14F
01/05 21:10, 14F
推
01/05 23:34, , 15F
01/05 23:34, 15F
推
01/06 20:59, , 16F
01/06 20:59, 16F
討論串 (同標題文章)
以下文章回應了本文:
完整討論串 (本文為第 42 之 49 篇):