Re: [討論] 念完資工之後...
※ 引述《tinlans ( )》之銘言：
: 愈是黑箱愈讓人擔心這件事，
: 是目前接觸程式設計越久的人越應該突破的心理障礙，
: 我也算是非常早期接觸程式設計的人，
: 所以我也能體會這種心態，
: 反正就是什麼都要看得非常透徹才會安心，
: 最好是 assembly code 會長怎樣都一清二楚，
: 但現在的軟體規模已經成長到當年無法想像的地步，
: 所以我選擇的是突破這種心理障礙，
: 否則永遠都會讓自己停留在過去。
這應該說是程式庫的 reliability 問題，這種事是一朝被蛇咬，十年
怕草繩的。
所以系統核心總是用 C 比較多，不只是自己安心，大家也安心。至於
其他部分，該用什麼就用什麼，我是很習慣多種程式語言和軟體共存
合作組織成一個較大的系統的。
這樣子就好了，把系統拆成不同層次，用不同方式對待，不管是那是
心理問題還是實質問題都能解決。
: OOPL 寫出的的 OS 要真的能上去還有得等，
: 但以市場角度來看這可能是唯一能寄予厚望的，
: 不過實現的時間點應該不會在你我還沒進棺材的時候。
這好像也太悲觀了... ^^|||
: 盲目的使用 OO design patterns，
: 和大量使用 OO design patterns 其實是不同的兩回事，
: 大量使用必有大量使用的理由存在，
: 其中之一就是需求變化量大，
: 所以預留了相當大的可變空間。
: 一個小有規模的軟體系統必有其歷史性，
: 存在少許的 OO design patterns 便能處理大部分功能的軟體系統，
: 就我個人經驗來說這通常是一個剛完成不久，
: 未經各種歷練的新生兒。
這個嘛，我持保留意見。
基本上我認為會使用大量 design patterns, 往往是沒有適當地使用
system pattern (稱作 architectural patterns 比較正式一點) 的
關係。
不管這些 system patterns 是以什麼形式出現，它們經常都可以有效
「集束」一些散落的系統流程，而不是在軟體的各個部分運用小型的
design patterns.
當然這樣子會損失一些效能，不能大量運用 template 而是依靠系統
元件之間的介面或內部通訊協定來完成，但就像為何要有資料庫系統
一樣，與其在軟體的各個部分做細緻的資料處理，使用著各種各樣的
複雜資料結構，往往不如整合成為一個獨立的資料處理元件，不只是
管省開發時間，也可做整體性的效能最佳化，未必就損失多少效能。
例如像 component-based programming (CBP), application framework
(AF), n-tier software architecture, service orient architecture
(SOA) 都曾風光一時，沉寂一時的 actor model 在學術界重新興起，都
代表著核心系統結構的魅力，它們都可視為一組有效的 system patterns
所構成的特定軟體結構，能有效減低軟體開發時在設計上的負擔。
OO 支持者，特別是 design pattern 的支持者，往往都認為那些結構
都只能解決特定問題，而忽視了為什麼一個特定的結構就能在一定的
範圍內如此有效，所謂的 pattern language 並不是只能在 'design'
階段可以應用，在系統架構上可能更具威力。
: 另外，
: 我不清楚你所謂「模擬」的意思是什麼，
: 一般而言，
: OO design patterns 與「模擬」二字應無關聯性。
許多商用系統的設計，其實就是原本的人工商業流程或舊系統工作流程的
模擬和取代，只是採用 OO design patterns 來做較高層次的抽象化。
這樣沒什麼不對，但其實可以再用純粹的軟體架構或電腦科學觀點做一次
重整，例如考慮 middle-ware 或 message system 的引入，用一個好的
系統結構，將系統切分成許多塊小型的相同物件，再各別做細部的設計。
在許多情況下，這可以發揮相當強的 divide and conquer 功效，彈性上
也不會損失，只有少許的效能損耗。
: : 這是系統安全的品質保證工作不確實，跟 OO 的關聯沒有想像中高。系統安全
: : 固然可以由程式語言來協助，卻主要還是 programmer 的 discipline 問題。
: 實務上是有相當大的關聯性存在，
: 這類工作不但負擔會因為 OO 化的落實而大幅減少，
: 施工時造就的 debug 時間成本也會大幅降低，
: 簡單一句話就是「減少因人為疏失而增加的時間成本」，
: 如同前面所說的，
: compiler 產生出來的 code，
: 總是會比 programmer 手工做得穩定。
: 即使是落實各種軟工中與 OO 和程式設計沒有直接關聯的理論，
: 這些由各 programmer 造就的時間損失依然存在，
: 否則的話，
: OOPL 從最初就不會被創造。
我倒是認為，許多人都太為看重軟體工具所能提供的效益，而忽視了人們自身
所能夠建構的規範。
例如每一個函數所傳入的資料都檢查、每一個呼叫所傳回的值也檢查過，難道
就是那麼不可承受的負擔嗎? 但幾乎沒有人這麼做，就光是想著依靠各種辦法
來偷懶，甚至把責任轉嫁到測試人員身上。
只要有好好做這麼一件事，那種要花大量時間找出來的 bug 就會少之又少。
又如絕不允許自己做 copy & paste, 碰到任何相似的程式碼都要再思考過，
若能有這樣的自我要求，再加上電腦科學的基礎，不管用什麼程式語言，都能
做出相當好的程式碼。
對於現在經常要使用多種程式語言來工作的 programmer 來說，把程式設計的
品質寄託在特定程式語言上，實在不是一件好事。
: 其實我要說的是，
: 因為只要拉拉元件照 example 寫 code 之類的工作，
: 已經漸漸有人在研發只要寫寫 spec 就能 generate 出 2/3 成品的工具了，
: 對岸的非菁英人才甚至是教育程度沒上大學的，
: 將來都可能從事這方面的工作，
: 所以到時候這些 coder 的水準會正式的降為作業員，
: 而台灣做這方面工作的人可能將會難以生存。
這東西在二十年前就有了，所謂的 4GL, iCASE 都是這類想法的產物，而且
多數都已實作出來了，但程式設計工作並沒有消失，只有愈來愈多。
所謂的 coder 難以生存的論點，也是在二十年前就有了，但結果不幸的是，
coder 的薪水是愈來愈好了，反而是 programmer 的生存愈來愈艱難。
世界上就是有著只會 VB 拿五萬薪水，能力中上的 C/C++ programmer 只拿
三萬多薪水的事（當然這不是通例，但也有一定的普遍性）
事情很簡單，因為專業軟體開發已經全球化了，而台灣是全球化的受害者，
能力強的不出國就只能寫 open source 軟體，而不是開軟體公司賺大錢，而
軟體應用服務卻十分在地化，大量簡易的客製化，特別是企業的網站和小型
資訊管理系統的需求仍然十分強勁，偏偏這是 programmer 不想做的東西，
裡頭有太多非技術性的成份。
在可預見的未來，軟體服務仍然會比軟體產品的需求更高，能做軟體產品的
高手們仍會繼續製作軟體開發工具和 open source 軟體，加強軟體服務的
技術支援。
而能力中等的 programmer 反而更要在乎中國和印度的衝擊。畢竟在地化的
小型客製化服務是很難全球化的，但專業產品製作及大型客製化服務卻容易
全球化，前者有無以數計在鄧小平 1984 年提出的「計算機的普及要從娃娃
抓起」口號之下，經過二十年逐漸培養出來的技術人才，後者有印度從美國
找來軟體工程大師們傾力打造的巨型軟體代工體制在世界攻城掠地。
所以最後到底是台灣的 programmer 還是 coder 死得比較慘，還未可知呢。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.173.26
討論串 (同標題文章)
完整討論串 (本文為第 6 之 18 篇)：
討論
22
91