※ 引述《tinlans ( )》之銘言： : 也要反觀 programmer 的素質讓這些人不敢如此做的原因， : 畢竟我看過絕大多數號稱是軟體工程師的人， : 拿 OOPL 寫出來的 code 完全降級成 object-based programming (ADT) level， : 甚至是 language 提供的 standard library 有的功能， : 也丟在一邊不用， : 去自己另外搞一個來， 我好像被你罵到了，所以出來解釋一下... ADT 沒有什麼不好的，超過十年前我就在玩 pattern 了，但現在幾乎都是在寫 C, 反而是急的時候才拿 C++ 當 rapid development tool, 多數時候就是拿來 做為 ADT 工具。 standard library 也未必合用。現在我已把它再包裝上一層，不再直接使用， 其中也有大半都已經配合作業系統做修改了，像是 windows 的 CRT library, 有一大半已經把 xxxx 變成 _xxxx_s, standard library 名存實亡。 其實沒有為什麼，因為高階程式設計的工具太多，會用到 C/C++ 時，往往都是 在做系統核心，愈是黑箱愈讓人擔心，若不是 CRT library 有 source 我都還 不敢用。 當然我知道你在說什麼，以前我也是這樣罵人，不過現在我可以理解，為什麼 大家都這麼用。這還不是台灣而已，全世界都這樣，你看看有幾個作業系統、 幾個系統軟體是用 OOPL 來寫的，能有 1/3 的程式碼用 OOPL 就很特別了。 這情況會慢慢改變，但不會很快改變。 : 要是拿到的 open source 程式碼太現代化 (用上大量 OO design patterns 等技術)， : 還好意思跟人家哭裡面的結構太混亂看不懂， : 所以不會擴充不會改， 大量的 design pattern 很少會是好的程式碼，因為複雜度並未有效降低，而 只是運用 pattern 來有效模擬，這往往表示分析設計工作並沒有做到軟體結構 重整，儘量使用最少量的 design pattern 來處理最大部分的功能才是王道。 當然軟體的複雜度，在沒有實作之前很難想像的，所以除非是極為高明的設計， 不然被抱怨結構混亂，實在是難以避免的。 : 寧可自己胡亂硬搞一個出來， : 造成本來不該會有的 bug 通通冒出來， : 最後的 product 問題一大堆， 這是系統安全的品質保證工作不確實，跟 OO 的關聯沒有想像中高。系統安全 固然可以由程式語言來協助，卻主要還是 programmer 的 discipline 問題。 : 你說這種結果讓公司高層怎麼敢砸錢砸時間去搞大東西。 : programmers 在學生時代就不夠用功， : 練習跟實務經驗都超級不足， : 這又會扯到教育問題， : 總之扯不完， : 我的意思是， : 並不能只是怪商人或公司決策有問題， : 資工人和資管人的平均素質也是一大問題。 : 就如同你說的「畫設計圖」， : 又有多少人能用現代化的技術畫出現代的設計圖來呢？ 我學電腦至今將近二十年也不會畫圖啊。不是說沒學過，我還是眼看著許多的 軟體工程方法慢慢演變的，大師們出一本書我就買一本書，也是花了好多錢， 但我從來就沒有碰過程式碼、註解、文字或 HTML 文件都還不能解決的系統， 要不然現在 open source 怎麼玩，沒看過哪一個專案有 UML diagram 的。 而沒有在用自然就漸漸地不會畫了，雖然我不否認設計圖很有用，但畫設計圖 所花費的心力不比寫程式少，在沒有需求的狀況下，畫圖多半變成不寫程式的 企業資管人員在做的事，但他們的工作績效沒有幾家企業能有效評估，往往就 變成良心問題了。 這我就不曉得該怎麼說了，產業體系就是這樣，只怕不是教育的問題而已。這 應該跟台灣以中小企業為主的經濟體制比較有關吧，畢竟主要是企業用軟體會 需要畫圖，在其他軟體的開發上是比較不需要的，而台灣的大企業很少。 : 這個惡化在台灣會有終結的一天， : 畢竟太多曾經是技術的東西都被弄得不太需要技術了， : 幾乎等於只要人力就可以搞定， : 遲早會被對岸取代掉， : 只是不見得是在這十年內。 對岸的技術，嗯，由於人口基數不對等，他們的菁英人數就比台灣的一般從業 人員還要多，而這些人的技術在相對上應該是遠超過台灣了。 雖然說拿對方的菁英對比本地的一般從業人員並不公平，但是以薪資和能力的 角度來看，台灣人的最大優勢，反而是在專業倫理上的壓倒性勝利，其他的都 沒什麼好比的。 換句話說，台灣就是強在滿地都是「好人」工程師，不然早就被取代了。這個 道德上的優勢，應該還足夠撐一段時間。只是資訊教育的失敗，仍然是極大的 問題，總靠著學生們出國留學來補，實在不是一個好狀況。 -- ※ 編輯: semop 來自: 61.222.173.26 (01/04 17:32)