ERP/MIS開發 ERP開發人員常犯的十種錯誤

經過數個ERP/MIS項目的開發，列舉常見的問題與錯誤，共勉勵。

1 界面代碼與邏輯代碼混淆

在項目的開始，一般都可以做到界面與邏輯的分離，界面只做數據綁定，業務邏輯則實現客戶要求的計算。

WinForms中的BindingSource和Web中的ObjectDataSource,可以實現對object綁定到界面控件屬性的功能。

這會帶來極大的方便，降低程序的維護代價，做到低耦合。舉例說明
采購單Sales Order的價格公式

Sales Order Price Amout=Item Price + Tax + Additional charge

采購單物料總金額=物料金額+ 稅金+ 附加費用(運費，保險費…）

Tax 稅金的計算，一般會根據物料的總金額，乘以百分比即可，是由系統自動運算的。
現在改需求了，客戶不需要考慮稅金，免稅，這樣公式即變化為
Sales Order Price Amout=Item Price +  Additional charge
公式中少了一項內容。如果界面和邏輯嚴格分離，這裡只需要改一下邏輯即可，不需要改動界面。當項目中發生這樣的需求改動越來越多時，業務與界面分離的好處會大大降低維護的代價。

2 不能適應需求變化

做ERP/MIS軟件，需求不可能沒有變化。即使是實施之後，修改起來比較麻煩，客戶願意出錢，也需要改動原來需求。

常見的需求更改：增加數據庫字段，添加更多的明細表記錄。增加數據庫字段是經常遇到的，如果你的數據綁定代碼是手寫的，或是拼湊SQL語句，這回你可真要痛苦一下，加一個字段會令你重新檢查所有的數據讀寫代碼。另外，界面也要添加控件，綁定實體的屬性。我的經驗是，設計代碼生成可靠，生成數據讀寫代碼，當增加數據庫字段後，只需要重新生成數據讀寫代碼，非常輕松的維護代碼。如果應用到ORM框架和數據綁定，增加字段只需要改一下界面即可，會更輕松。

3 缺乏足夠的邏輯驗證Validation代碼

用戶的輸入總是有各種問題的，要常常記得驗證客戶的輸入。設計自定義的控件,NumbericInputBox,CurrencyBox專有來輸入數值數據，貨幣數據，可以減少很多驗證代碼。其次，在保存數據時，要驗證數據的主鍵是否重復，檢查外鍵的字段是否已經存在，這些檢查是必要，盡管SQL會幫忙你找出錯誤，但是，終究是你沒有寫驗證的原因。
ERP/MIS開發，驗證也是體現邏輯的一個地方。工作單過帳時要檢查物料清單是否有效，工序是否已經確認，下銷售單時，要判斷客戶的信用額是否超過預定的額度，大量的驗證代碼存在於ERP/MIS系統中，請添加足夠的驗證代碼，而不是假設用戶的輸入或系統的判斷是正確的。

4 沒有始終貫徹接口與實現分離

在項目開發前中期，我們預定接口與實現一定要分離，像這樣的
public interface IAccountManager {  }
public interface AccountManager  {  }
調用方法
IAccountManager  accountManager = ClientProxyFactory.CreateProxyInstance<IAccountManager >();

可是，當項目處於不停的維護和修改的狀態時，我們常常會偷懶，寫出這樣的代碼
IAccountManager accountManager =new AccountManager ();

這種偷懶也是要付出代價的，前一種標准的寫法，可以實現WCF,.NET Remoting通信框架的互換，而不影響任何代碼，CreateProxyInstance這個方法裡面，可以做的事情太多了。前一種寫法，可以實現cache緩存接口實現類，而後一種方法則無法做到，前一種方法，可以減少編譯時的依賴，完全在運行時才解析出需要的類型。

5 對部署/應用環境沒有做周全的考慮

我們開發的代碼，沒有對代碼的執行環境做很全面的檢測。比如，客戶的電腦沒有安裝.NET 3.0/3.5,我們寫的Linq代碼就會出錯，如果沒有安裝.NET 4.0，用到並行類的方法也會出錯。如果客戶安裝的Crystal Report的版本與我們開發時引用的版本不一致，代碼執行時，會發生FileNotFoundedException異常，Report Viewer控件也是如此。客戶的機器上沒有安裝Reporting Services，而我們的代碼也沒有檢查Reporting Services服務是否存在，就開始讀取它的報表項來呈現報表。如果競爭對手想試用你的ERP/MIS系統，把你的軟件裝在虛擬機中，對於依靠檢測系統日期來判斷是否過期的驗證方式，則在虛擬機中改日期後，你的對手可以有足夠的時間來消化學習你的系統。
對此，要充分考慮軟件的運行環境，做出判斷以減少低級錯誤。

6 對系統的更改和維護缺少設計規范(Design Specifications)

你的系統維護是否是這樣的，客戶說要改，你就馬上開始改代碼。老板說要改一個地方，你也毫不怨言的打開VS.NET，開始修改代碼。這樣是可以的，但不可取。客戶要改，盡管他和老板的關系好，但你也要先記下來，當面溝通後，事後寫個郵件給你的上司，說明有哪些任務要做，有哪些修改。這樣做，一來是因為你的上司給你發工資，你的工作只對上司負責，不是對客戶負責，二來是，記下來後，再書面確認一下，以防止客戶抵賴或是溝通不充分。在不需要交修改維護費用的情況下，客戶要改的東西實在是太多了，有時候可能客戶因為心情不好，把你叫過去說半天，改這裡改那裡，等下班了回去之後，客戶他自己都忘記了要改什麼了。溝通不充分的問題，主要是怕你誤解了客戶的意思，或是說客戶沒有說明白，既然客戶是上帝，上帝是沒有錯的，那就是你的理解錯了。所以，事後用書面形式再確認一下，會是增加溝通效果有好辦法。這個維護修改的書面表達形式，就是要說的Design Specifications。把客戶要改的東西，放到標准的Design Specifications模板文件中去，打印出來，拿給客戶簽個名，他會很重視自己的說過的修改。我有曾見過厲害的客戶，他明明知道這個修改有些不合理，但是工作完成後，等驗收時，完全是按照他的意思做的，他也表示滿意。這就叫做信譽，下次再找我改需求，我肯定會很樂意。

7 沒有隔離第三方軟件/控件供應商的組件變化

在我們的項目中，常常會引用一些第三方的控件，因為他們強大，好用。但是，我們還需要自定義一套控件，用來隔離這種第三方控件的變化。第三方的控件供應商，會常常更新它的API，屬性和方法，如果項目中缺少這種隔離，則控件一變，我們的所有代碼都需要改變。舉例說明，第三方控件WebGrid,有一個屬性DisplayLayout，用於顯示界面元素，我們在ERP/MIS中大量應用到這個屬性。如果有一天，WebGrid把這個屬性DisplayLayout改名為Layout，這下慘了，我們要改的代碼太多了。推薦一個好辦法是，重新這個第三方控件，加入我們的自定義屬性
public class Grid:WebGrid
{

      pubic DisplayLayoutDisplayLayout;
}
當第三方的組件WebGrid把屬性DisplayLayout改名為Layout，我們只需要這樣做

public class Grid:WebGrid
{

      pubic Layout  DisplayLayout;
}
引用此控件的ERP/MIS代碼則不需要任何變化，即可適應第三方軟件的API的變化。

8 報表開發與定制缺少必要的文檔，公式和字段來源說明

這是我們公司ERP維護的一個困境，有大量的客戶會要求實施人員幫忙定制一些報表。隨著時間的推移，ERP維護人員走了一批又一批，當初定制報表的存儲過程，修改的目的，文檔也丟失了，很難從幾百上千行的代碼中，找到合適的理由，為什麼要這樣修改。工作多年後，雖然習慣了看沒有文檔的代碼，習慣看沒有說明和注釋的代碼，只好硬著頭皮幫忙客戶找SQL，找報表的存儲過程，一點點的修復bug。ERP/MIS中，與數據有關的bug會占有很大的比例，就因為數據的不同，程序無法作出適當的處理，出錯。雖然現在已經用建立Sharepoint建立了以客戶為目錄的共享文件夾，但要維護好客戶的需求記錄，還真不容易做到。

9 沒有考慮數據庫的可移植性

我一直都很佩服Oracle的市場宣傳做的很好，從開發人員到工程師，從老板到銷售助理，一提到數據庫，都會提到Oracle。有時候銷售助理，會大肆宣揚Oracle的好處，甚至比開發人員還懂得多。也有的客戶，指定只用Oracle,拒絕用其它的數據庫，沒有任何理由。所以，如果是做一個長期的產品，還是要考慮將來數據庫移植的問題。數據訪問，要用通用的DbConnection,DbCommand，DbDataAdapter,或是用ORM；少用存儲過程，多用程序代碼來實現邏輯。在系統開發時，開發人員常常只是理論上實現了多種數據庫的支持，真要到真實的多種數據庫平台中跑一下的時候，問題會接二連三的來了。以SQL語句，選擇前十行數據為例子
MySQL 和PostgreSQL : SELECT * FROM emp limit 10
Oracle :  SELECT * FROM emp WHERE rownum<=10
SQL Server :  SELECT TOP 10  *  FROM  emp
我的建議是，如果要支持多種數據庫，盡早做規劃，盡早建立真實的數據庫環境測試。

10 對命名規范(文件，控件，變量)不能始終堅持

以舉例為證，窗體類一般會在後面加個frm來表是是窗體類，如SalesOrderfrm,所有顯示報表的窗體，後面加rpt,如SalesOrderrpt。 這裡有個小技巧，為什麼不是rptSalesOrder,而是SalesOrderrpt。這是為了在IDE的Solution Explorer視圖中，以方便的看清同一組的窗體而以此命名的。如果我再加一個報表SalesOrderQuotationrpt,這樣，在Solution Explorer視圖中，這兩個報表窗體是顯示在一起的，方便查看。

對於控件，請看下面的命名
private EPN.WinUI.Editors.TextEditor txtRevisedBy;
private EPN.WinUI.Misc.Label lblLastRevised;
private EPN.WinUI.Editors.DateTimeEditor dteRevisedDate;
private EPN.WinUI.Misc.Button btnPrint;

txt表示TextEditor,btn表示Button,lbl表示Label.

日期格式，有的地方是用yyyy-MM-dd，但是有的地方是yyyy/MM/dd,沒有統一。

價格Price字段的長度，是decimal(12,4), Amout合計字段的長度是decimal(16,4)
對於這些規范，要始終的堅持。如果可能，可以開發一個Code Analysis規則，來自動分析程序集。