多層式架構的更新

DELPHI的最大討論區(就筆者的感覺)，應該就是K TOP了，近日看了一篇文章  面對快速持續改善的多層架構系統要如何規劃版本更新架構呢？  覺得很有趣，於是就做了一些回應，想不到一些淺見還得到大家的討論，所以說明一下本人的程式更新方式。還請大家多多指教。

首先，我們會把程式做一些分類，然後做一些存放程式位置的規定。

接下來，會有一個共同的檔案管理區，這個區域存放大家寫的程式，當個人要修改程式時，就要從這個區域CHECK OUT程式，這時程式就得屬CHECK OUT的人了，除非該名程式人員把程式更新CHECK IN，否則是不可以更動的。這樣才不會有程式互改的情形發生。

因為DELPHI這種語言的特性，基本上就是為程式人員設計的，所以大家寫的程式都是在自己的電腦上做測試。在自己Local的開發環境上開發程式是有道理的，因為這時你負責的程式你最大，你可以依自己的方式來解決問題(當然還是要遵守一下大家的規定，例如預設值的EVENT位置、引用適當的公共程式，而不要自己寫一套解決相似問題的程式等)，這樣程式的開發效率最快，DEBUG也很容易。

程式測試OK後，就會把程式上傳到共同的檔案管理區，這時個人的程式就告一段落了。

程式的更新分為AP端和Client端。如果狀況很緊急，程式馬上要用(例如不更新程式就沒辦法發薪水)，那就用平台工具更新資料庫，並把AP程式和Client放上主機。然後請使用者從新進入系統，當使用者使用到更改的功能時，就會自動下載Client端程式，然後用新的程式運作。

至於不緊急的程式，可以等大家都下線時做更新，因為有一堆人做修改，其實也很難知道每一個人改了什麼。但是可以確定，就是在共同管理區的程式是可以正確WORK的。那就用平台工具，把資料庫CREATE一次(平台工具會先比對TABLE，有修改的才做修改)，再把程式全部重BUILD，COPY到主機。這樣更新的工作就完成了。主要是資料庫和AP程式會同步更新，Client端是使用者有用到程式，才比對做更新。

沒有特別好，也很平實，不過會有問題通常都是程式人員程式有BUG，很少是更新的錯誤。

程式人員最重要的工作-思考並下決定

最近因為工作上的關係，在公司寫了一篇專題文章  待辦事項vs警告和提醒，如果有興趣的朋友，可以參考一下。

我們在完成系統時，往往花了很多的時間去確認程式的完整度和測試程式是否有BUG。在花了這麼多的時間之後，如果要加上待辦事項，或是異常的警告；這時就會面臨一個抉擇，是要修改原來的後端過帳程式呢?還是獨立用另外一組程式來做新功能?

如果只是一二個程式的修改，一般都會選前者；不過如果是會一直追加的功能呢?例如異常的提醒就是會一直加的功能。首先會是一二個異常的提醒，例如庫存不足時提醒。接下來USER就會說那庫存都可以提醒了，那支票到期是不是可以提醒?上班忘刷卡是不是可以提醒?主管簽核超過時間可否提醒?....然後你就會發現異常的提醒功能可能不會比ERP系統小。

這時如果你選擇的是前者，我想這時程式應該已經複雜到很難改變的地步了，要再找人訓練應該有困難了。如果你選的是後者，那至少系統比較好理解，可以分派給不同的人，擴充性是比較好的。

這樣講好像很簡單，問題是一開始都只是一二個小問題，怎會知道後面會變化這麼大?都改了這樣一大堆程式了，那是要回去重頭選擇第二種方式，把程式改回去，還是就這樣用第二種方式，程式繼續給他複雜下去?

判斷是程式人員最重要的工作，選對上天堂，選錯下地獄。千萬不要聽信USER給你的訊息，你一定要自己加以判斷，後續的變化和追加是不是會很多?因為那都會變成你的工作量。我相信你想過，做了決定，不論是對是錯，你心理都會舒服一些，因為那是你選的。

選錯了沒關係，在系統沒變複雜前，修正過來就行了。重要的是你想過，知道你為什麼做了這樣的選擇。這樣經驗多了，你的選擇對的機率會提高很多。

Flow，再討論一下Flow

Flow這個幾年前電腦公司大力宣傳的口號，日前正用另一種方式在企業界發聲--線上簽核。

筆者覺得線上簽核對資訊人員而言是一個大工程。線上的保密、資料的傳送，加上IOS和android不同平台的程式要寫，工程真的很浩大。

不過線上簽核對企業的幫助是不是很大?用小小的螢幕要簽核文件真的方便嗎?

工作流程和待辦事項 這篇文章大家可以參考看看。雖然有提到一些Flow的做法和應用，不過筆者覺得，目的是什麼?它有沒有被達成，是比較重要的。技術只是達成目的的手段。

WEB前端列印

最近筆者和客戶見面，談到WEB的一些解決方案。發現有些工程師覺得Browser就是在WINDOWS上執行的程式，所以列印方式應該和在WIN FORM上的列印方式應該很接近。其實Browser為了安全性和本身作業的獨立性，不會和作業系統做很緊密的結合。
因為Browser有這樣的特性，所以要做類似ERP報表套印的程式，就變的比較麻煩，筆者寫了一篇有關 WEB列印 的文章，大家如果有興趣，可以連進去看看，參考一下。
對WEB老手來說，這應該是基本知識了，如果你剛進入WEB寫HTML，希望這篇文章對你有幫助。

DataAware簡易說明

最近一直在忙做產品的影片，其中有做到在WEB上的DataAware。如果對DataAware案例有興趣的朋友，可以參考一下 DataAware的簡介說明 這個影片。

既然都提到DataAware了，就來說明一下它的應用和好處吧。我們在做程式設計時，畫面顯示的資料和資料庫儲存的資料，基本上是連動的，一般而言，以下圖為例

左方的GRID如果筆數更改，右方EDIT的對應欄位也要跟著改變。同樣的如果右方EDIT修改內容，左方的GRID內容也要跟著改變。因為是他們都是同一筆資料。


現在問題來了，每個對應的欄位都要寫程式去改變其他元件(GRID、EDIT、CHECKBOX等)，工程是不是太大了。如果資料TABLE加一個欄位，是不是程式又要加一堆互動的程式?

DataAware就是為了解決這個問題。它的原理是以DataSet為中心，所有和DataSet有關的元件，只要有值變更，就會通知DataSet，然後DataSet再通知相關元件做資料的更新，達成資料的一致性。

有了DataAware和資料感知元件，程式人員就不用花心力在資料的同步上，可以減少大量的程式負擔。