接下來，我們就要開始進入實戰階段，預計分四個主題來談：

1.標準化---樣板程式
2.元件化---底層共用程式
3.自動化---Wizard
4.系統化---用程式自動化管理，不要有過多的人工管理。

統稱之為開發四化。今天我們先來聊聊前面 2個主題

標準化

所謂的標準化，主要是從下面幾個面向來討論
A. 樣板程式：

每支程式的第一個版本，都是透過Wizard依據樣板程式產生，然後再由程式設計師(programer)，增修完成交付的版本。

這樣做的優點是

• 確保每支程式的程式架構一致，任何受過訓練的程式設計師(programer)都能互相維護彼此寫的程式。
• 程式是由專案經理(PM)或系統分析師(SA)，使用Wizard產生。並可依該版本程式和User確認規格，可避免溝通不良導致的規格不明確。
• 輸入規格到Wizard程式後即可產生第一版程式，大幅提高開發生產力，而且程式也避免人為撰寫程式的疏失。

B. 呼叫共用程式或SQL 的預存程序(Store Procedure)

用Wizard產生的程式碼，只能產生大部份的通用標準程式，還是會有部分程式碼需要手工撰寫。而程式會出問題，大都是出在這個部份，所以程式設計師(programer)在手動撰寫程式碼時，務必依循下列標準的作法。

• 如果有共用函式(function)，請呼叫標準程式庫中的FUNCTION。如果沒有，請和系統設計師(SD) 討論是否要寫新的function加入共用函式庫中，除非是很特殊的需求，一般都請寫成functon。
• 如果是複雜的運算邏輯，且和資料庫的內容有關，可以和系統分析師(SA) 討論後，請資料庫管理員(DBA)，寫成預存程式(Store Procedure)，供程式設計師呼叫。.
• 如果都不是，則可以由程式設計師自行撰寫程式，但仍應將程式碼封裝為function，且需依循開發SOP的相關規範。

C. 程式碼的風格一致化

此部分主要當然是針對手工加入的程式碼所做的規範。主要的目的是讓程式碼易於閱讀及維護。

• 程式碼一定要加入註解，且註解必須有固定的格式(依SOP)
• 程式新增的變數必須遵循命名規則

標準化的目的，是讓程式碼易於維護。

如果沒有相關的規範，不同的程式設計師，根據自己的喜好，寫出風格完全不同的程式碼，這對後續維護的程式設計師而言是個大災難。稍有經驗的開發人員都知道，程式完成後的維護成本，事實上是遠高於開發成本的。因為開發成本是一次性費用，但維運卻是長期的成本。

一套資訊系統(ERP)，使用的期限通常都很長(至少5-10年)。除非有重大的變動，否則不會輕易更換系統。而且隨著企業內外部環境的變動，系統也必須配合而作出必要的調整及修改，所以易於維護(擴充)，絕對是讓資訊系統能長期使用的重要因素。

元件化

此處筆者所謂的元件化，事實上泛指兩個概念

Component (元件)
Library (共用函式庫)

A. Component：
早期 Windows 時代，如Delphi或 Visuai Studio2012 ... 等，可以直接拖拉元件盤上的元件到程式中，透過設定相關的property(屬性)及Event(事件)後，即可運行。常見的 Label、TextBox、DataGrid、ComboBox等一系列的 UI 元件都屬於此類。

近期新的 Web 開發框架，也都強調組件化，例如 Vue.js 陣營，就有 Element UI 和 iView 2套強大的 UI 組件庫，就是很好的例子。

另外大型一點的元件，如: iCale行事曆元件、Reporting View報表元件則是更高階，功能更豐富的元件。使用這些元件可大幅強化系統的功能，而無須投入太多的人力資源，所以善選好的元件也是非常重要的。

最新的技術通常就表示還有待時間的考驗，選用third-party元件也是同理。

選用元件的第一守則是一定要選擇已被驗證可行的元件及技術(如已有完整的文件庫及廣大的使用者，或已有大廠的支援)，才可以考慮整合到開發平台中。開發平台的整合，本來就是件勞心費力且帶點運氣的工程。在專案起始的初期，大部份的心力都會花在平台元件的整合。除非已經確定開發平台都已整合且測試無誤，否則就不應該邁入功能開發階段。

B. Library 共用函式

• 框架底層的共用函式
  通常是配合Wizard產生程式時所需呼叫的共用函式庫。
  例如，我們常會將連接資料庫的連線程式(DB Connection)，寫成共用程式。一般而言，程式不應直接呼叫，大都是一般較高階的共用函式呼叫，或是Login時就已建立好，這類程式皆屬之。

• 一般共用程式
  大部分的共用程式(function)皆屬之。
  舉凡限制查詢條件用的共用程式，或是記錄使用者功能的log、印表時擴充取xml定義的function等。
  這類共用函式大都隨著開發的進行而逐步加入、擴充，是共用程式庫的主要構成元素。

通常，元件的來源有三

• 開發工具內建
  這是最大宗的來源，如Visual Studio 2010就提供一系列完整的元件供使用。

• third-party廠商提供
  購買third-party廠商提供的商業化版本。
  此類元件通常功能非常豐富。另外，現在開源程式(open source)，也有非常多好用的元件，也可以考慮採用，但必須注意其授權方式，以避免商業使用時的糾紛。無論是哪一種來源的元件，都必須謹慎的選用及測試，才能納入標準的開發平台。

• 自行開發
  如果找不到合適的元件，例如首頁顯示時所需要的數位儀表板元件，就只能自行開發。原則上如果能找的到現行的元件，就盡量選用，避免投入太多的人力到元件開發上。

元件化的好處非常多

1.首先，程式碼大幅的精簡。
2.再來，程式的可靠性大幅強化。

程式設計師只要查看相關的文檔，就能使用功能強大的元件，等於大幅提高功力一甲子，並從中學習元件的架構的規劃。當累積足夠的使用經驗後，即可嘗試自行開發元件。

什麼是軟體工廠?

軟體工廠一向是所有開發人員的夢想，而元件化則是實現軟體工廠的最重要基石。

軟件工廠的真正意義是希望軟體的開發能像資通訊硬體產業的設計組合方式一樣。如果您打開您的PC、NB或Smart Phone的外殼就會發現其內部最主要的構成機件是(主機板+ICs+其他被動元件)。

手機晶片則有高通、聯發科的多款 ARM 架構。中國幾年前剛開始發展手機時，所謂的白牌手機(或山寨版)，之所以能掀起大風潮，主要是拜聯發科的(一條龍公板)策略所賜。原本手機開發技術只掌握在少數國際級大廠的手中，有極高的進入門檻，一般廠商根本不得其門而入，只能望門興嘆。但是聯發科的破壞性創新策略，憑藉其優異的手機晶片及公板，讓山寨手機廠商能快速的設計並推出功能強大的平價手機，並快速佔領市場。這就是元件化的優點，如果沒有聯發科，中國所謂的山寨市場就難以形成。

如果軟體設計能像硬體一樣，設計好主機板，然後有取之不盡的IC可以組合使用，然後就可以設計出一套新系統，光用想的就程式設計師們無限神往，從此不用日以繼夜的加班加到爆肝，再也不會被客戶追得滿街跑。

不過，這畢竟是 I have a dream，雖然已經有很多的國內外工具廠商投入大量的資源研發，但是目前的元件化技術，還是只能有限度的達到ISV(獨立軟體開發商)的需求，還是有很大程度的程式碼需要手工開發。

早期 MS-DDS時代，國內工具大廠訊光科技曾經推出DBTOOLS這套超強工具。這套系統當初造福了不知多少ISV廠商及企業，它就很接近筆者理想中的Wizerd。

到了Windows時代，另一家工具大廠聯銓資訊，以 Delphi 5為基礎開發的VDP，則是另一個令人驚豔的產品。這些國內廠商開發的工具，大幅度的提高了軟體開發的品質，並降低軟體開發的門檻，可以說對國內的軟體產業做出了很大的貢獻，本系列文的部分觀念，也借鑒了這兩套產品的優點，可見一個好的產品影響有多深遠。

總而言之，元件化是整個開發平台的核心，就像想要蓋101大樓，就必須先打好地基。想要寫出一套優質的企業資訊系統，就必須先將元件化整合好，這是整個開發團隊必須先建立好的共識。