ERP/MIS开发 ERP开发人员常犯的十种错误

时间:2022-08-16 23:17:58

经过数个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规则,来自动分析程序集。