這個主題是寫給外行人和新人看的，沒有嶄新或厲害的高深內容。

只是以個人角度的，軟體開發的歷史的一個經驗縮影而已。

分兩段，一段是web2.0時代以前的商業應用軟體開發經驗，後面一段則是web2.0時代以後的，大概是相同目的的應用軟體開發經驗。

只是相對簡單的商業應用軟體開發，組合語言或驅動程式的韌體與底層通訊應用程式等等就不在涵蓋範圍內，因為傻蛋那方面沒多少經驗啦。

本篇為上篇。

開始吧。

剛開始接觸軟體程式開發應該是唸大學的時候。

高中一年級時，1994年吧，其實學校有教過basic程式語言。

但傻蛋分配到的電腦教室的電腦剛好在後排，每次開機後...就當機了，完全追不上前面老師在講的東西，跟不上進度，這是傻蛋高中唯一一次不及格的科目。

就為了這個理由，痛恨小孩打電動的父母才會買電腦，讓傻蛋高中時可以用電腦玩電腦遊戲。

或許也因此，傻蛋這個高中是唸文組的學生，才會在大學聯考的時候填志願填了個政大資訊管理系看看，就剛好上了。

因此而沒有唸法律系，或許真的是一種好運吧，上了大學系上有商事法必修課，還有民法可以選修，上過課才發現法律系的課程內容和想像的不一樣，那是一種說不出來的奇怪感覺啊。

真正開始寫程式是從大一的計算機概論課程開始的。

那時候是學C語言。

傻蛋因為有高一時的失敗經驗，所以小心謹慎，自己去買書來提前練習。

好像是本叫邊做邊學C語言的書吧。

就是一些簡單的範例，透過可以執行看到結果的回饋，學習簡單的程式開發。

那些範例簡單，用途有限，但不難懂，所以，大概學會了如何用軟體程式來作一些簡單的事情那樣的概念。

所以在大家都怕的要寫程式上機考試交作業的計概課程，傻蛋不需要參考同學的作業，可以自己搞定，成為同學裡面那種可以寫程式的人的一份子。

是的，可以寫出一些簡單的程式，可以有一點點用，但實際上，沒太大實用價值。

畢竟那個時候已經是視窗作業系統流行的時代了，用鍵盤輸入互動為主的人機介面的程式，簡單說就是太難用。

所以當時開發簡單商業應用程式的主流，不是C語言，而是各種視窗應用程式開發的工具環境。

最有名的就是傳說中的VB6。

而VB有點在程式語言的鄙視鏈下游，沒關係還有Visual C++，Borland C++ Builder，PowerBuilder，以及當時傻蛋還蠻喜歡的Delphi等等。

其實開發的概念是大同小異，基本上就是事件驅動的應用程式開發。

怎麼開始？

先拉一個表單當入口。

然後可以從可用的組件裡面拖拉到畫面上，放兩個文字輸入和一個按鈕，然後在按鈕點兩下快速建立按鈕點擊事件的處理function，第一個文字輸入是帳號第二個是密碼，處理的function裡面用邏輯判斷帳號密碼是否正確，正確就可以關閉登入畫面，然後開啟另外一個表單頁面，那樣第一個表單畫面就做好了。

可以有很多細節，但基本概念就是把組件拉到畫面上，控制哪個畫面要顯示，控制組件上的資料狀態，有那些互動，互動的事件該怎麼繼續往下走，那樣而已。

所以登入後要跳到怎樣的畫面，照你想的設計，如再拉一個首頁的表單，然後在頁面上放置menu的功能選單組件，每個選單點擊事件可以再切換顯示表單，又或是只是要切換同一個表單內顯示的組件，那都是可以的。

那是一個以元件為基礎的軟體開發模式的時代。

坦白說，多數簡單的應用軟體開發的需求，用那個模式的工具來實現，其實已經很足夠了。

就算是需求很複雜，功能眾多，只要規劃架構得當，其實也是很適用。

不需要太多學習，拖組件到畫面上，點兩下寫一點程式，然後把程式跑起來，看看執行起來的效果是否是期望的樣子，學習這種軟體開發比學C語言的開發容易上手許多，而且很快看到預期成果的樣子。

或許檔案與數據庫的操作會稍微複雜點，但呈現結果用的表格等等很直覺，上手的難度是很低的。

現在很多快速開發雛形畫面當系統規格的情境，有些工具就是當年的這種開發模式的重現而已。

物件導向程式設計，對於以元件為基礎的這種視窗應用開發來說一點也不重要，也不容易因為亂設計亂繼承導致系統維護難度的飆升。

很實用，很好學，相對直覺，不算複雜，不過這種開發模式，目前應該算是過去式了。

為什麼這個簡單好學的應用軟體開發模式會成為過去式？

一個主要的訴求是，這種方式開發的軟體對環境依賴度太高。

開發完的程式，可以透過一種叫install shield的打包程式，打包成光碟安裝程式，放進光碟自動跑安裝精靈，安裝完成後桌面上出現快速連結，很方便，看起來也有點專業。

但不是每個作業系統都能跑。

可能開發打包出來的程式，在微軟的作業系統可以跑，但在蘋果的作業系統或Unix的主機上，則根本不能用。

甚至還有，微軟的某些作業系統版本支援，舊版或升級後的新版本支援就有問題會不能使用。

也就是說，如果要開發一套軟體產品，給各個平台各作業系統使用的話，程式碼就要為每個環境準備一個版本。

那是多麼可怕的成本。

所以就出現了所謂的跨平台的程式開發工具環境的需求。

這也就讓目前軟體開發的龍頭，Java隨之而誕生了。

初衷，或是早期主要訴求，的確就是跨平台。

傻蛋記得升大二的暑假，老師還組織讀書會，把Java的原文書印出來拆一章一章讓同學分著讀，一起討論，然後說要用這個新技術去接案子那樣。

坦白說當時讀得是似懂非懂的。

只記得，目的是跨平台，手段是透過虛擬機的中介，在執行之前都編譯成相同的中介程式碼，然後與不同環境的適應問題透過虛擬機去適應就好，那樣的概念。

所以最初，那個Java的定位曾是，只要用同樣語法寫一次，可以在所有支援虛擬機環境的平台上運行那樣的訴求。

但是，Java語言其實也就是類似C語言的程式語言罷了，並沒有對標當時流行的應用程式整合開發環境如VB6那樣的開發模式。

然後Java又是真的要做物件導向的程式語言，而非簡單的以元件為基礎的快速整合開發環境而已，所以，用Java的開發方式和以前是完全不一樣的。

初期的Java如何開發使用者介面？

當時主要的使用者介面是用網頁呈現的。

有java Applet與Java server page兩種，那就是在網頁標準下來實現使用者介面。

是更酷更炫的感覺，但要做到以前常做也很容易做到的事，要學得更多，而且更費工，開發出來的應用程式也更複雜更不好維護。

至於跨平台，多數商業環境的系統都是內部使用，或對跨平台需求不是很強烈的，其實新技術並沒有實質生產力提升。

唯一的影響或許是，以元件為基礎的假物件導向被真物件導向程式設計取代那樣。

這個變革的時間點，主要是使用者介面從過去的整合開發環境的視窗表單，逐漸往網頁呈現遷移吧。

而當時也開始有很多用現在所謂的後端網頁技術，如早期的ASP，現在還很多人用的PHP，以及目前應該死得差不多的JSP等等，來做系統的開發。

畢竟網路泡沫之前，確實有一波網路狂潮吧。

而動態頁面的應用程式，天生就有跨平台的效果了，只要支援相同瀏覽器，那就只要一個版本就可以，另外，原本的應用軟體開發是單機軟體為主，而實務上會有很多是現在雲端系統這樣的集中遠端軟體的需求，所以網頁應用的軟體開發就很快變得更加重要。

或許也和單機時代程式容易盜版複製有點關係。

總之呢，使用者介面就逐漸的以網頁形式或介面，成為主流，傳統視窗軟體的使用者介面需求就變得不是那麼熱門了。

另外還有設計思維的改變。

原本主流的設計思維並不是物件導向，而是程序導向設計。

物件導向是新發明出來的不明覺厲的新東西。

傻蛋唸大學的時候大概對物件導向的印象也是這樣，有點玄，好像很厲害，理論上可以減少重複的程式碼，但也就是感覺，不太清楚具體要怎麼應用在分析設計時的實務用途。

所以呢？

看別人怎麼做，模仿看看那樣吧。

反正要實現的結果還是一樣的，就讓實現的過程用的程式看起來是物件導向的就好。

找物件，決定物件的屬性與方法，然後再看有沒有會用到酷炫的繼承。

反正兜得起來就好了不是嗎？

至於設計得好不好，就有點看感覺。

經驗還不夠的時候就是靠感覺而已。

看起來有模有樣的，然後有達成需求的功能，這樣就很好不是嗎？

差異就是，程式設計師很多時候會用物件導向設計來做需求與流程分析時的標準，因為必須要套物件屬性方法那套物件導向的東西進去。

然後呢？

程式的入口點在哪裡，如何一行一行從上往下執行，往往這些軟體程式語言最重要的基礎就被物件導向設計給隱藏起來了。

無論如何一個軟體程式總是有跑起來的入口點與實際運行的流程規則，傳統程序導向設計時這些點通常不會藏得太神奇，只需要弄清楚這是單純函式庫的功能還是事件驅動形式的軟體功能，要看懂一個程式，那個結構會比較好猜。

然而物件導向套下來就難說了。

特別是複雜的需求，會有大量的物件。

而物件本身就是物件，就是屬性和方法組成的而已。

看待領域的角度不一樣的時候，選擇的物件模型可能是完全不同的設計。

同樣的程式碼，兩個人看到的＂我以為＂有可能是天差地遠的解釋。

總而言之又言而總之，物件導向程式設計，從事後的觀點來看，可能不是什麼厲害的魔法，反而讓一些糟糕的程式設計師靠這個製造了很多沒有價值的複雜度出來而已。

但是，物件導向設計基本上已經形同行業標準，也因此有物件導向相關的設計模式跑出來，簡單說就是抄別人的作業那樣。

那些設計模式其實又和物件導向本身有類似的情況，確實可以硬抄然後做出一些東西來，但如果抄的人不知道怎麼連結實務需求和要抄襲的設計模式，為了套用而套用，那就只會製造更多沒意義的複雜度出來而已。

其實有人整理出物件導向設計原則，那些原則倒是值得深入理解，因為，那是實務上使用物件導向發生的問題與無效率後，歸納整理出來的原則。

那些原則可以讓設計的人知道為什麼要這麼做與不應該那麼做，而不是不明覺厲。

例如，經過業界多年的經驗，得到的共識，物件導向設計，要避免使用繼承，而是要改用組合取代繼承。

繼承不是物件導向的大殺器嗎？

狗繼承動物，所以狗是動物，狗有動物的所有屬性和方法。

柴犬繼承狗，所以既是狗又是動物。

好像很好用。

實際上繼承的用處很有限，副作用卻很大。

因為一不小心，就會繼承到奇怪的屬性方法。

如果邏輯非常嚴謹，可能幾乎都不會用到繼承，反之，可能會覺得有點像，就給他繼承下去。

然後使用物件的時候看到有一些繼承來的屬性方法，很高興，已經有了不用再自己寫了，好棒那樣。

然後呢，會碰到以為的和實際的是不同的囧境。

還有一種情況是，有兩個屬性或方法看起很像，都很像自己要用的，不知道該選哪個。

而且一但某個物件的類定義繼承了另一個類，那就是終生定義上綁在一起了，如果後面發現有某個情況，不應該繼承，那，有此需求時，是否要重複大部分相同的代碼，來產生一個新的沒有繼承原本不適合繼承對象的新類？

那會變成哲學問題，問到你懷疑人生的。

看到一個很像的屬性或方法，深入去研究，有可能差一點點不完全是你需要的定義，又不完全不是，那怎麼辦？

改原本的設計，會影響到其他原本的使用者。

所以呢？

保險一點就是另外增加自己需要的定義與實踐就好對吧？

當看到一個用途的屬性有好多個長得很像的屬性時就知道那個苦與亂了。

當套了一知半解的東西，一整套套下去，其實就是一整個繼承的概念。

而只使用自己充分理解掌握的工具與方法，就是靈活的使用，就會比較接近組合的概念。

如何？

如果不是真的受過物件導向設計之苦，這一段這樣讀下來應該繞得蠻暈的。

如果堅持用程序導向的思維設計軟體應用，只要專注做好模組化設計，還是可以做到相同的功能。

或許可能還比較簡單一點。

但無論如何，物件導向設計仍是目前絕對的主流，至於另一個更走火入魔的功能設計，讓語法更抽象，更需要高智力的人來閱讀理解，最近熱度好像又沒那麼高了，後續會怎麼發展就讓我們慢慢走著瞧吧。

還記得這一篇長文說的分隔點嗎？

Web2.0時代，傻蛋認為是很大的分別。

至少在Web1.0時代，軟體開發還是和之前的思路是大致繼承下來的。

用動態網頁開發應用程式只是困難度與工作量比整合開發工具的模式費工點而已，根據需求決定畫面設計，然後實現需求的分析設計邏輯大致還是差不多的。

然而到了Web2.0時代就不一樣了。

Web2.0時代應該是用非同步呼叫的技術的大量使用來做為劃分的。

傳統的後端網頁，每一個動作就是要請求一個新頁面，後端服務器收到新的請求動作後回傳新的狀態的html頁面內容給瀏覽器顯示。

這種設計在一些簡單的畫面輸入檢查時會顯得很沒效率。

之後就逐漸有使用前端瀏覽器那邊的功能，使用那個Javascript來操作前端畫面的需要跑出來。

一開始，或許只是每點一下畫面整個閃一下的改善方案。

微軟的那個失敗的ASP.net Ajax很貼心的為了過去時代思維的工程師提供了相對簡單的解決方案，只要用類似拖拉的方式使用組件，就可以做到某一個框框裡面的部分更新可以不用整個畫面全部閃一次整個重新產生一次。

然而Web2.0的關鍵不在於那個多閃一下還是少閃一下的體驗差異。

而是對軟體的使用介面和數據狀態流程做邏輯上的分離的一整個概念上的大轉變。

怎麼說呢，或許又和iPhone的大成功也有關係。

通用型智慧手機上的應用程式商店的出現產生了很大的改變。

如果系統建構的時候，前後端邏輯有分離好，那麼那個App其實也就是另一個操作介面的途徑而已，而商業邏輯可以和網站介面用相同的一組程式。

更不用說智慧型手機還有兩個陣營的需求需要滿足。

所以，在非同步的api呼叫的web服務大量流行之後，整個產業生態是有很大的改變的。

如果不把架構做前後端分離設計，那一但面對雙平台App加上網頁版的操作需求的時候，人家邏輯只要做一套，你要做三套，還要處理三套之間的邏輯與狀態一致問題，成本比別人高太多，就會沒有競爭力。

後面的，是當前的狀況，就留到下一篇再繼續寫了。