DirectShow的迷思

看到台湾人写的文章 还不错

http://tw.myblog.yahoo.com/oneplay.tw/article?mid=10&sc=1

由於近年影音產品越來越重要, 以微軟作業系統為基礎的程式開發技術, 首推DirectShow.

也發現越來越多中小企業的老板, 聽其他人講到DirectShow, 然後瘋狂地要以DirectShow來開發產品.

在此, 要以我自身的經驗及瞭解, 說一說DirectShow這個東西倒底是什麼?

DirectShow其實是一個軟體架構方法的實現, 而不是什麼很驚人的語言技術.

講得難聽一點, 這是給不懂軟體架構及軟體工程的程式開發人員一個偷懶的方法, 也就是懶人軟體架構技術.

從好聽的方面講, 這是微軟以COM為基礎設計出的一統架構, 讓不同公司, 不同的軟體開發人員可以利用相同的架構定義分別開發程式, 卻能互用對方所開發出來的模組.

要真正懂DirectShow架構的真諦, 就不能不面對軟體架構方法, 以及軟體工程各方面的知識; 許多的老板, 只是一味聽別人說DirectShow如何如何, 誤以為DirectShow是多媒體設計的萬靈丹, 以為導入DirectShow可以幫助產品產生多少的執行效能.

這種想法有相當的問題; 在此告訴看文章的讀者, DirectShow本身並不會對所寫的程式增加任何的執行效能, 它只是軟體架構方法而已.

那為何有那麼多人誤以為它能帶來執行效能的提升呢? DirectShow是一個借力使力的架構, 如果程式設計師都依循微軟對Filter寫作所訂定的標準, 那就能提供給其他程式設計師使用, 所以, 它的概念在於, 每個程式設計師, 甚至於每一家公司, 在多媒體技術上所專精的會有差異, 比如像我的老東家, 它並不需要專精codec寫作的程式設計師, 所以可以購買專精於codec寫作的公司所寫的codec Filter, 而把精力花在其它(例如影像處理)等等地方, 如果沒有codec能力很強的公司, 寫出powerful的codec Filter, 那引入DirectShow, 在encode/decode的執行效能上, 依然不會得到比以前更好的執行效能.

再者, 人員會有流動, 但Filter一旦寫好, 很容易重覆使用, 所以對公司的技術累積, 會有相當的助益.

但是, 若要充分發揮DirectShow架構的好處, 最主要是軟體開發部門要有較完整的軟體工程規劃.

DirectShow所用的軟體架構, 就是Pipe&Filter Architecture罷了, 只是在這個軟體架構下, 微軟有許多已經開發好的Filter可以現成拿來用, 減少了許多程式設計師麻煩, 不用每一個細節都需專精, 借力使力才是它的精髓.

目前業界充斥著一堆靠"年資"升上去的軟體開發主管, 正在殘害新一代資訊工程畢業生; 開發軟體產品還在用蠻力和暴力, 這樣的主管, 最多的就是在電子製造業, 因為電子製造業一直以來, 著重於工廠的生產, 直接相關的又是硬體研發部門, CEO多數都覺得軟體開發隨便找個程式寫個十年以上的人來帶就好了, 而沒有注意到軟體開發的"專業性", 軟體寫得久, 只能代表他在軟體寫作技巧上懂得比較多, 但不能代表他會懂軟體"開發"這檔事, 就像很會修車的那些老師傅, 一輩子修車, 可能修的技術很好, 但不代表他懂如何有效率的修車, 或保證每次修車都遵循一定的規則, 這也就是為什麼, 台灣常常在拆完引擎再組裝回去後, 永遠多了一堆螺絲, 不知道哪裡忘了裝, 然後丟進水溝裡.

看倌可以自問以下的問題, 來判斷是否還在用蠻力開發程式, 在軟體開發技術上還只有老經驗修車師傅的水準而已:

(1)什麼是Design Pattern?(懂這個, 只能當Senior Engineer)

(2)何時使用Desing Pattern?(懂這個, 才能做一個Leader)

(3)什麼是OOAD? 主流的軟體開發流程有那些? 優缺點各是如何?(懂這個, 才剛入門當主管)

(4)什麼是軟體架構? 主流的架構有哪些? 各可以用在何處?(懂這個, 快要升成主管)

(5)軟體工程是什麼?

(6)見過或甚至已導入Issue Tracking嗎? 有哪幾種Issue Tracking?

(7)現在是把CVS, SourceSafe, SVM當作網路硬碟, 還是版本控管工具? 有放入class diagram嗎?

(8)知道什麼是單元測試(Unit Test)嗎? 有在做嗎? QA需要負責的測試和研發人員所要做的測試有何不同?

(9)對於團隊成員的考績如何計算? 憑印象? 還是有標準計算公式?

台灣要自強, 要自詡能開發出高品質的軟體產品, 要有高品質軟體產品, 首先要有高品質的軟體開發流程.不要說因為看不到立即的成效, CEO才不會支持中階主管導入軟體工程; 這些中階主管們, 自己做了什麼? 有太多軟體工程上要做的事是要從自身開始, 而不一定需要CEO來主導, 先做出一點點成績, 自然而然可以讓CEO漸漸接受, 才有全面實施的機會.