I encourage you to list common problems and errors after several ERP/MIS projects.
1 Interface Code Obfuscation with logic code
At the beginning of the project, the interface and logic can be separated. The interface is only used for data binding, and the business logic implements the computing required by the customer.
Bindingsource in winforms and objectdatasource in Web can bind an object to interface control attributes.
This will bring great convenience and reduceProgramLow coupling. Example
Price formula of the sales order of a purchase order
Sales order price amout = item price + Tax + additional charge
Total amount of materials in the purchase order = material amount + Tax + Surcharge (freight, insurance ...)
The Calculation of tax is generally based on the total amount of materials, multiplied by the percentage, which is automatically calculated by the system.
Now, the customer does not need to consider tax and tax-free, so the formula changes
Sales order price amout = item price + additional charge
One item is missing in the formula. If the interface and logic are strictly separated, you only need to change the logic here, and you do not need to change the interface. When there are more and more such changes in the project, the benefits of business and interface separation will greatly reduce the maintenance cost.
2. Unable to adapt to demand changes
The demand for ERP/MIS software cannot be changed. Even after the implementation, the modification is troublesome, and the customer is willing to pay for it and needs to change the original requirements.
Common requirement changes: Add database fields and more detail table records. It is common to add database fields. If your data binding code is hand-written or pieced together with SQL statements, you may suffer a little bit, adding a field will allow you to re-check all data read/write code. In addition, you must add controls on the interface to bind the attributes of objects. In my experience, the design code generation is reliable, and the data read and write code is generated. When a database field is added, you only need to re-generate the data read and write code, which is very easy to maintain. If it is applied to the ORM framework and data binding, you only need to modify the interface to add fields, which makes it easier.
3. Insufficient logic Validation Code
There are always various problems with user input. Remember to verify customer input. Custom Controls are designed. numbericinputbox and currencybox are used exclusively to input numerical data and currency data, which can reduce a lot of verification code. Second, when saving the data, verify whether the primary key of the data is repeated and check whether the field of the foreign key already exists. These checks are necessary, although SQL will help you find out the error, after all, it is the reason why you did not write verification.
ERP/MIS development, verification is also a reflection of the logic. When posting a work order, check whether the bill of materials is valid and whether the process has been confirmed. when placing a sales order, check whether the customer's credit has exceeded the predefined credit limit, A large amount of verification code exists in the ERP/MIS system. Please add enough verification code, instead of assuming that the user input or system judgment is correct.
4. interfaces and implementation separation are not always implemented
In the middle of the project development period, we must separate the predefined interfaces and implementations.
Public interface iaccountmanager {}
Public interface accountmanager {}
Call Method
Iaccountmanager accountmanager = clientproxyfactory. createproxyinstance <iaccountmanager> ();
However, when the project is constantly maintained and modified, we often get lazy and write such code.
Iaccountmanager accountmanager = new accountmanager ();
This kind of Laziness also has to pay the price. The previous standard writing method can implement WCF ,. net remoting communication framework interchange without affecting any code. In the createproxyinstance method, too many things can be done. The previous method can implement the cache interface implementation class, but the latter method cannot. The former method can reduce the dependencies during compilation, the required types are parsed completely at runtime.
5. No comprehensive consideration for deployment/application environments
The code we developed does not fully detect the code execution environment. For example, if the customer's computer does not have. Net 3.0/3.5 installed, the written LINQ code will go wrong. If. Net 4.0 is not installed, parallel methods will also fail. If the version of the Crystal Report installed by the customer is inconsistent with the version referenced during development, a filenotfoundedexception exception occurs during code execution, as is the report viewer control. Reporting Services is not installed on the customer's machine, and our code does not check whether the Reporting Services Service exists, so we can start to read its report items to present the report. If a competitor wants to use your ERP/MIS system, install your software in a virtual machine, and determine whether the verification method expires by checking the system date, after changing the date in the VM, your opponent can have enough time to digest and learn your system.
In this regard, we should fully consider the software runtime environment and make judgments to reduce low-level errors.
6. design specifications are missing for system changes and Maintenance)
If your system maintenance is like this, the customer says you want to change the code immediately. The boss says you want to change a place, and you can open vs. Net without complaint and start to modify the code. This is acceptable, but not desirable. The customer wants to change the relationship. Although the relationship between the customer and the boss is good, you must first write down and send an email to your boss in case of face-to-face communication to explain the tasks to be done, what are the changes. In this way, your boss pays you a salary, and your work is only responsible for your boss, not the customer. Second, write it down and confirm it in writing, to prevent customers from credit or insufficient communication. If you do not need to pay the maintenance fee for the modification, there are too many things that the customer wants to change. Sometimes the customer may call you for half a day because of their bad mood, after work, the customer forgets what to change. Insufficient communication is mainly caused by the fear that you have misunderstood the customer's meaning, or that the customer has not been clarified. Since the customer is God, God is not wrong, that is, your understanding is wrong. Therefore, it will be a good way to increase the communication effect if you confirm it in writing afterwards. The written expression of this maintenance modification is the design specifications. Put the customer's changes in the standard design specifications template file, print them out, and sign them for the customer. He will pay great attention to the modifications he has mentioned. I have seen a very good customer. He knows that the modification is unreasonable, but after the work is completed, he will be satisfied when the acceptance is complete. This is called credibility. I will be happy to ask for another change next time.
7. Component Changes of third-party software/control vendors are not isolated
Some third-party controls are often referenced in our projects because they are powerful and easy to use. However, we also need to customize a set of controls to isolate the changes of such third-party controls. Third-party control vendors often update their APIs, attributes, and methods. If such isolation is missing in the project, the control changes and all our code needs to be changed. For example, the third-party control webgrid has a property displaylayout, which is used to display interface elements. We have applied this property extensively in ERP/MIS. If one day, webgrid changed the displaylayout attribute to layout, this would be miserable, and there would be too much code to change. We recommend that you re-use this third-party control to add custom attributes.
Public class grid: webgrid
{
Pubic displaylayoutdisplaylayout;
}
When the third-party component webgrid renames displaylayout as layout, we only need to do this.
Public class grid: webgrid
{
Pubic layout displaylayout;
}
The ERP/MIS code that references this control can adapt to API changes of third-party software without any changes.
8 required documents, formulas, and field source descriptions are missing for report development and customization.
This is a dilemma of ERP maintenance in our company. A large number of customers will ask implementers to help customize some reports. With the passage of time, ERP maintenance personnel went through a batch of different batches, And the stored procedures, modification purposes, and documents of customized reports were also lost, it is difficult to find the appropriate reason from hundreds of thousands of lines of code and why to modify it like this. After many years of work, I am used to reading the code without documentation and the code without instructions and comments, so I am forced to help the customer find SQL and find the report storage process, fix bugs a little bit. In ERP/MIS, data-related bugs account for a large proportion. Because of the differences in data, the program cannot properly handle and make mistakes. Although a shared folder with the customer directory has been created using Sharepoint, it is not easy to maintain the customer's requirement record.
9. Database portability is not considered.
I have always admired Oracle's marketing efforts. From developers to engineers, from bosses to sales assistants, Oracle will be mentioned whenever we mention databases. Sometimes sales assistants will publicize the benefits of Oracle, and even know more than developers. Some customers only use Oracle and refuse to use other databases for no reason. Therefore, if it is a long-term product, we still need to consider the problem of database transplantation in the future. For data access, use common dbconnection, dbcommand, dbdataadapter, or Orm. Use less stored procedures and use more program code to implement logic. During system development, developers often only implement the support of multiple databases theoretically. The problem may come one after another when they really need to run on multiple real database platforms. Take the SQL statement as an example.
MySQL and PostgreSQL: Select * from EMP limit 10
ORACLE: Select * from EMP where rownum <= 10
SQL Server: Select top 10 * from EMP
My suggestion is that if you want to support multiple types of databases, plan as soon as possible and establish a real database environment test as soon as possible.
10 naming conventions (files, controls, and variables) cannot always be adhered
As an example, the form class generally adds an frm to the end of the table to be a Form class, such as salesorderfrm. All the forms that display the report are followed by RPT, such as salesorderrpt. Here is a tip: Why is it not rptsalesorder, but salesorderrpt. This is to name the form in the IDE's Solution Explorer view so that you can easily see the form in the same group. If I add a report salesorderquotationrpt, the two report forms are displayed in the Solution Explorer view for ease of viewing.
For the control, see the following naming
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 indicates texteditor, BTN indicates button, and LBL indicates label.
Date Format. In some cases, yyyy-mm-dd is used, but in some cases, yyyy/mm/DD is not uniform.
The length of the price field, which is decimal () and amout total is decimal)
Always adhere to these specifications. If possible, you can develop a code analysis rule to automatically analyze the assembly.