過度工程化(Over Engineering)」是個在軟體開發領域中很常看到的現象,在過去我們也約略談過。所謂的「過度工程化」,在軟體開發的範疇裡,指的就是:「預想的比實際需求的多,以致於投入更多的資源,卻做出額外、不在真實需求內的東西」。

就我觀察到的現象,在軟體開發的領域裡,過度工程化的情況可能出現產品功能規畫裡,也可能出現在系統架構設計的時候。

當我們在規畫產品時,會試著設想使用者的需求,並且規畫對應的功能及操作情境,使得使用者透過這些操作情境可以滿足使用者的需求。最常見到的迷思就是,錯以為愈多的功能、愈強大的功能,因為能滿足愈多使用者的需求,所以,就愈能讓軟體顯得更有威力。

因此,在基於打造更強大軟體的想法下,規畫產品的人,往往就會試著為軟體加入更多、更強大、更複雜的功能。

但是,使用者的真實需求沒有那麼多,而規畫產品的人卻想的更多,使得軟體提供了遠超出使用者真實需求的功能。這些功能看起來讓軟體變得更好,因為它們提供了更多、更強大的功能,但是,這些功能滿足的,卻只是想像中、虛無飄渺的使用者需求,或者是或許會被用到、但卻很少會被需要的需求。

更多功能意味著更高的研發與製造成本,需衡量必要性

提供更多、更強大的功能並不是毫無代價。倘若這是個汽車的行業,規畫汽車產品的人正在規畫一部家庭房車,對車子來說,車子的速度當然愈快愈好,因此,如果這部家庭房車的極速,可以超過每小時 300 公里,一定可以成為一個很好的產品。如果,增加車子的極速毫無代價,那或許可以這麼考慮,可惜,如果一部汽車想要極速超過每小時 300 公里,它起碼得要有馬力更大的引擎、能傳遞更大動力的變速箱、適合高速行駛的底盤、更大尺碼的輪圈及輪胎、……等等。這些條件都意謂著更高昂的成本。

當然,諸如 BMW M5 之類的高價房車是沒有問題,但是,這是因為它的售價足以支持如此高昂的成本。因此,我們在市面上不會看到每部房車都能提供這麼高的極速,大多數的家庭用房車都設定在平常家庭使用需要的速度範圍內。

關鍵在於「真實需求」,絕大多數對於家用房車的真實需求絕對不是極速很高、加速很快,而可能是足夠安全、空間充足、省油、甚至還包括價錢合宜、……等等。因此,試著為一部設定為普羅大眾用的家庭用房車,配備一顆足以隨時奔上時速 300 公里的引擎,肯定是「過度工程化」了。

從汽車的例子很容易明白「過度工程化」的概念,也能輕易明白絕大多的家庭房車不需要擁有直上時速 300 公里極速的動力。可是,在我們規畫軟體的時候,卻也時常可以見到過度工程化的情況-賦予軟體一些目標群眾其實不需要的功能,但自以為可以讓軟體變得更好用、更強大。

當我們開發超出實際需求的功能

軟體的過度工程化,也是一樣並非毫無代價。雖然,軟體本身在完成後的複製代價幾乎為零,但是軟體仍舊有著高昂的開發成本,而過度工程化的代價也大多反映在開發時的成本之上。當你規畫了愈多、愈強大、愈複雜的功能,你的架構就可能要愈複雜,也需要花費愈多的人力投入開發,你的開發成本自然就變高。

而且,就和所有過度工程化的問題一樣,提供了使用者在真實需要之外的功能,其實沒有實際的作用。而且,還有可能因為功能更多,使得軟體變得更複雜、更不易使用的負面效應。

規畫軟體產品時,要留意是否落入了「過度工程化」的陷阱,功能很多、很強大,有時不是表面上看到的那樣美好,而是需要付出開發成本做為代價的,而且,更重要的是,多花費的成本所換到的東西,卻都是使用者不會用到、不常用到的。

架構設計過度的誘惑

除了規畫軟體時會有過度工程化的陷阱之外,很常見到的,在設計軟體程式架構時,也容易踏入過度工程化的陷阱裡。而且,通常功能沒有到一定境界的軟體設計者,還不大容易掉落過度工程化的陷阱裡。對那些自己對於技術感到自豪、覺得應該要苦心打造出厲害軟體架構的設計者來說,往往才是容易踏入這個陷阱的族群。

技術能力沒有到一定程度的人,光想著如何實作出規格就可能耗去所有心思了,更別提要過度工程些什麼。但是,有能力、有企圖的人就不一樣了。他們對於自己所設計的架構有所期許,他們更希望可以打造出一流的系統。這樣的出發點想法絕對沒有錯,但是也容易引導他們往過度工程化的方向去走。就像一個有野心的汽車產品規畫者,開始想要打造一部地表最快速的家庭房車,卻不理會售價、市場區隔、成本、 ……等等問題一樣。

不能盲目追求擴充性

許多軟體設計者都和厲害的數學家、物理學家,對於「universal」的概念(即萬用、通用)存著夢想。數學家和物理學家都想找出一大統的理論,來解釋所有的情況。而軟體設計者,都想設計出萬用的架構,提供絕佳的擴充性,只要寫好平臺或是核心,就可以輕易在上面進行各種擴充,來增加不同的功能。

好的擴充性絕對是正確的方向,但是問題是,你需要多少的擴充性?你所設計進來的擴充性,是否超出了實際的需要?而為了增加這些不需要的擴充性,會付出多少代價?擴充性如此、效能亦如此。好的效能也絕對是正確的方向,問題是,需要多少效能?真正的效能瓶頸在那裡?

效能如此、規模可擴充性也如此。有好的規模擴充性也絕對是件好事,但是你得思考你真正需要的規模可擴充性有多少?倘若一個最終只會有小型規模的系統,卻配上了極佳的規模可擴充性,而且為了取得此一規模可擴充性,還付出了沉重的代價,那麼這樣值得嗎?這樣應該嗎?

優秀的軟體技術人員都崇尚優美的架構,像是有好的擴充性、好的規模可擴充性,但也因此,時常讓他們在追逐此一目標時,忽略了真實的需要,以致於做了超越真實需求的產物。

問題的關鍵,看來就在「真實的需要」究竟為何了。每個人都可以評估真實需要的界線究竟在那裡,可是,每個人的評估也都不盡相同,也不一定準確。我相信有人可能可以預測的頗為準確,不過我是一個比較偏市場實證派的人。我喜歡盡早讓產品在保有適當(擴充性、效能、規模可擴充性……)的情況下,先推到市場上接受考驗,但不一次做到頂。

這樣的好處是,省下了若干開發時間,你可以更快速的收到市場及使用者的回饋,收集到關於「需要」的更真實資訊。即使目前有所不足,你可以在發展下次的版本時,演化到真實需要的層級上,或者,即使目前滿足需要,但也可以預見即將會有那些新的需要產生,盡早開始布局,以便下次演化時可以更容易。

持續演化和一次到位是兩種截然不同的哲學,持續演化是透過不斷的收到回饋及調整,來適應或瞄準我們的目標。透過快速持續演化,探索真實需要的方式,可以避免落入過度工程化的陷阱之中。

專欄作者

熱門新聞

Advertisement