作者reader (讀者)
看板CSSE
標題Re: 關於這個板討論的問題
時間Mon Jan 3 22:20:26 2005
※ 引述《CGary (煙霞)》之銘言:
: 看你用甚麼Scale來看待演算法...
: 對於我學習以來的觀感, 演算法的確是程設的核心, 不, 應該說算是思考
: 的核心, 思考本身就是如何用"有效"的方法, 解決問題, 這就是演算法的
: 精神...
這個問題其實就是電腦科學和軟體工程的分別。
電腦科學只能考慮「問題如何被解決」,而軟體工程看見了「問題
需要被解決」,或者更明白地說:「需求必須被滿足」。
是的,需求,沒有人的需求就沒有程式設計這件事。
人的需求是千變萬化的,很可能是讓軟體看起來更漂亮、更有趣、
更好用、更快、更酷、更棒、更便宜,也可能是不要常當機、不要
出現錯誤的答案,甚至使用者自己都說不出來真正的需求是什麼,
看到東西他才知道那是不是他要的。
軟體工程所要面對的,就是在這個不確定、糢糊、感性的世界裡,
尋找堅實有效的方法滿足需求。而在軟體產業當中,有了答案才有
問題的狀況,更是層出不窮,真正的創新往往是在問題沒有出現、
需求沒有被發現的情況下,展現出超越一般人想像範圍的新應用。
從問題到需求到創新,真正激勵人心,讓前仆後繼的才智之士投身
軟體工作的,唯有創新。
如果不站在滿足需求的立場上看待程式設計,並以此上求創新下解
問題,那麼,我們很可能會走入歧途,卡在語言與機器之間,窮經
皓首推求精微,反而失卻當初喜歡程式設計的本源初心,也離開了
人心與義理所在。
: anyway, 除了演算法問題以外, 資料結構, 語言結構, 都算是程式設計很
: 重要的問題
: 雖然有些領域的東西, simulation甚至領先理論的研究, 但是演算法的確
: 是十分重要的核心關鍵, 這邊講演算法並不是只包含像是Quick Sort,
: Merge Sort這種製式Algorithm, 而是整套方法論
: 當你開始遇到一個問題時, 你總是很自然開始用一套方法解構這個問題,
: 然後開始讓整個問題break down成所謂的function, 比如說你遇到一個
: 河內塔問題, 當你知道大概可以怎麼做之後, 你會開始選擇撰寫的語言,
: 然後開始針對需要的"變數"來設計, 接下來等等等的....
: 開始break down問題的方法, 就是在設計演算法, 所以我也是屬於你所
: 不認同的網友唷:)
: 正統科班出身的, 大概到最後玩語言的方向, 不外乎都是這三種東西
: 演算法/計算理論/PL
: 資料結構
: 編譯器
我喜歡也敬仰電腦科學的深奧幽玄,也曾浪擲青春費心探索,然而,
自己從未忘卻,我是如何為世界的無盡苦難悲憫痛惜,從而關心社會
問題,最終理解到唯有溝通和發展才能真正解消問題,並認識到唯有
科技才是第一生產力,唯有資訊科技才能同時促進溝通和發展。
於是,我面對著電腦,實際上卻還是在面對著人,日復一日的工作和
研究,忍受著沒有盡頭的孤寂,始終是為了眾人而服務,為了文明的
進一步發展而努力。
當我要寫程式時,首先面對的,不是問題,而是人。所要解決的,也
不只是個別的特定問題,更是人的需求和感受。
進一步來說,所有正規軟體工程方法的開端,總是由定義需求開始。
需求的分析研究管理,遠比程式設計的實作細節更重要,而在開發的
期間,軟體配置管理 (SCM, software configuration management)
也始終會是一個關鍵性的重要課題,所有的一切,都圍繞著「需求」
而走。
需求是不清晰的、不確定的、會變動的、會發展的,是現實的,也是
心理的,不是死板釘釘的一個個學術問題。
軟體工程取代電腦科學,成為主導軟體開發的指導知識,已達三十年
以上,其間的弊病問題以及有待發展的領域,仍然十分眾多。特別是
在創新管理方面,更是接近一片空白。
然而,學校教育體系所教出來的學生,卻往往對軟體工程的認識十分
不足,知其然而不知其所以然,在觀念上更往往以科學工作者自居,
重視解決問題而不重視生產和創新,出社會有著適應不良症狀的比比
皆是,於是數十年來,主導當今軟體工業發展的一群人,有許多都是
沒唸完大學的人,在知識高度密集的行業中,蔚為奇觀,也不是毫無
因由的。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.173.26