[軟體工程] 製造業 vs 軟體業

本人不學無術，只有看過一些文章，上過幾次課而已。本文是根據作者以稀少的親身體驗和think too much的哲學性思考，所得到的一些想法。感謝我的摯愛提供大量background。

---

製造業，就我所了解，是一種「別人叫你做什麼就做什麼」的行業 (話說回來，大多行業都是如此吧)。別人提出需求、下訂單，然後廠商就按照需求，經過設計、製造，把東西做出來，有必要的話，最後會量產批發。似乎產製任何東西都可以套用這套流程，畢竟它會經過計畫以後再進行，小心翼翼地做事比較不會老馬。一切都很合乎邏輯，非常直覺～

那麼，這種製造方法，適不適合用來做軟體呢？

「有什麼好不可以的？先知道要做什麼，再進一步分析設計開發測試，哪裡有什麼問題？」
沒錯！先做好計畫再進一步動手工作確實是很正常、很正規、很傳統的流程，而這套流程模型，在軟體工程當中有一個聽起來很專業，背後意義卻很簡單的專有名詞，為「瀑布式模型」。
瀑布式模型 (waterfall model) 是至少20年前的東西了，但是現在還是非常普遍地在使用，原因無它，就是因為它的理念很簡單：先明白需求、再經過分析、設計，再進行開發，最後再測試和上線。流程上非常的合理，就像製造業在產出任何一樣東西，也是先要知道要達到什麼目的，才會去設計它、量產它。而且有經過精心的分析和設計，所以對產品的品質有一定程度的保證。
流行二十年的東西，代表它有一定存在的價值，就像BBS一樣，早期的技術到現在還在用。


事情真的這麼簡單的話，我就不用在這裡靠夭了。

---

試想，你是一個使用者，而今天需要開發一套系統來讓你的工作更為順利，你能夠很明確地告訴系統分析師或是跟你訪談的那個人說「你需要什麼」嗎？不要覺得這很簡單，其實這是有難度的。這中間往往會發生你覺得你已經講得很清楚了，分析師還是聽得一蹋糊塗(這不能怪他！全世界熟悉你的工作的人只有你自己，對他來說那都是新的東西)，或者是你根本就沒講清楚，然後軟體寫好了以後才發現根本幫不上你什麼忙，一切都是白搭。更不要說，從敲定需求以後到開發完這段時間，需求又在不斷變化。最後怎麼辦？要不是做出來的東西根本幫不了用戶，就是讓開發程式的人改到死。

因此，瀑布式模型可能會適合一開始就需求很明確的專案，然後經由嚴謹的流程來保證產品的品質；但是絕對不適用於連使用者都不是很清楚他自己想要什麼東西的情況。
微妙的是，大部分的軟體開發專案，使用者都不知道想要什麼，而且瀑布式模型用得非常開心。據說，十年前的作業方式就已經是這樣了，而且現在還沒有什麼改變。（前途真堪慮）

事實上，實際在操作開發方法時，有時候還會再加入一些額外的小機制，來降低需求浮動的風險，像是利用雛型來挖使用者的需求、分割子系統、加入風險管理機制.....等，而科學最厲害的地方是，只要一點點不一樣，就可以把它講成是很不一樣的東西。只是，它們都還是一些waterfall-based的開發模型，本質上並沒有多大的改變，問題根本不會解決。

而製造業和軟體業產出來的產品，差別在於：製造業者如果夠不要臉，他大可以說「我東西都做好了，不爽不要用，要改就要拿錢來，你沒看到這個成品的成本要花多少錢嗎？」；而軟體業沒有「實體」，所以看起來好像不需要成本，只要和神(ㄒㄧˋ)燈(ㄊㄨㄥˇ)巨(ㄔㄤˇ)人(ㄕㄤ)許個願，就可以把一個九九乘法表程式變成Excel引擎。（請原諒我用很酸的方式來陳述這件事，因為我真的很酸）
如果你是寫程式的人，你聽到使用者這樣講，不會覺得很逼機嗎？尤其是每當他們要改什麼東西的時候就說「只是變成OOXX而已，要修改應該很快吧！」

好了。現在我們知道：做軟體的，不能把需求看作是一個不會變化的常數，而要看作是一個會變化變數，而且變動幅度可大可小，端看推動專案的技術和手腕。那麼，這應該怎麼去操作呢？

---

這種問題在十幾年前就已經被發現了，當時也提出了一些方法來改善這個問題，像是演進式策略 (Evolutionary Development Strategy)、拋棄式策略 (ThrowAway Strategy).....等。演進式策略，簡單來說就是由已經確定不會再變化的地方開始先行開發，再慢慢一個階段一個階段地完成細部設計和開發，以完成系統。這方式同樣也很容易理解，但是容不容易做到又是另一回事，假如SA/SD功力不夠渾厚，辟邪劍法練之前沒先自宮，沒辦法分辦哪些東西是可以先開發，哪些東西是還不明確的，這樣的作業方式風險更大，而且，需求可能是一個階段一個階段累加上去的，所以恐怕會有系統難以維護之虞；而拋棄式策略則相反，先用很簡單、粗糙的方式快速開發出需求還不明確的地方，再和使用者做進一步的溝通，反正那也只是做確認用，用完就丟掉了，但是呢....開發拋棄式軟體一樣要時間要人力，意味著這些東西成本，做出來的軟體都是產物，然後用完就丟掉，等於在成本上是一種浪費。

既然上面這兩種方法都還有這麼明顯的缺點，那我提它幹嘛？
在距今十多年的時空，Kent Beck提出了極限編程 (eXtreme Programming, XP) ，它的概念就有點類似演進式策略，但是卻又更加的積極去面對需求的變化。其實它的立場，並不會去壓抑需求的變化，反而是將它視為理所當然，而且是一定會需要面對的一環。無法逃避、不能退縮！
而極限編程強調一點：要求團隊在開發的過程必須朝正確的方向前進，在一次又一次短暫的階段循環當中不斷地修正策略，每個階段開始之前要先有個簡單的計畫、每一個階段開發少量、且確定是使用者需求的量，讓程式有效利用的程度最大化，並且仔細看寫完的程式是否能夠模組化、是否能夠更加精簡化，如果能夠精簡化，是必須要有改掉重修的覺悟和勇氣的，使開發和維護一次到位，一切從簡，不需要太複雜的設計。

還有一點是很特別的：Kent Beck認為開發程式不需要太多浪費許多時間產出的文件，只要有 C4 測試案例就搞定了！
「開始寫程式之前，先把自動化程式的測試案例先寫好再說！」
藉由撰寫自動化測試的程式，讓程式設計師來省視自己對需求的了解情況，待許多自動化測試的案例完成以後，才開始開發程式的主題。一隻程式寫完以後，需經過自動化測試來檢查程式的正確性；許多程式寫完並整合再一起以後，需經過自動化測試來觀察整合的情況。總之，開發程式的過程就是不斷的測試開發測試開發測試開發測試開發測試開發測試開發....
至於文件，Mr. Beck是認為不太需要，有大量的測試案例，中間還有許多會議中要呈現想法的UML圖，就足以表達需求、設計或演算法的內容，而且寫文件容易流於形式，搞到最後花了一大堆時間去寫，到最後對軟體開發的過程一點幫助也沒有。
極限編程的要點大致上就是如此。設法讓工作量最小、滿足最大量的需求，並且透過大量的自動化測試案例來維持程式的品質，再更詳細的內容，擇日，了解更深入的極限編程技術後再與大家分享。

如此的作業方式，就需求變不變化就不是問題了，那根本不是問題，而是一定會發生的事。需求一定會隨著時間有所變化，正視這些變化，而並非壓抑它，讓產出來的程式能夠精準有效地滿足客戶的需求。系統在開發的過程隨時保持高度的彈性，以利於軟體擴充及維護，所以被視為敏捷式開發 (Agile software development) 的一種類型。

兩大種方法
如果你是客戶，你希望得到怎樣的服務？
如果你是開發商，你希望你的客戶得到怎樣的服務？
如果你是程式人員，你希望你的作業方式是哪一套？

---

這個概念被提出至今，已過了十多年的時間了，這段時間，Kent Beck仍然設法不斷簡化流程。這套方法在國外已陸陸續續被使用且接受；而國內，就我目前所看到，雖然有些勤奮不懈的小人物大英雄們在默默宣導推動著，但是還是使用傳統開發方法居多。原因嘛....除了無能、沒有遠見、沒有勇氣等，可能還有一些華人的教育、人性因素、環境因素等在裡面作祟。

回到主題「製造業 vs 軟體業」，我聽說這陣子的成衣業有一種很新潮的製造方式：設計衣服的廠商會先做出各種不同的板型，然後釋放出來，再統計看看哪些板型的衣服，因為哪些原因而賣得比較好，再把這些很夯的因素加進板型上，再大量釋出版售。
這個做法，和extreme programming的概念有些類似。時代的演進當中，製造業的作業方式也在不斷在進步，為了生存而研發、實務了一套適用於這個時代，滿足廣大需求的推動方式。
以高科技產業自居的軟體業，卻仍抱著二十年前的作業流程不放。要是給外國人還是外星人知道，大概會被笑到把台灣倒插在海底吧....

哪個傳奇英雄來改變一下台灣的軟體科技業吧！