1- You Should Comment your Tables and database objects to facilitate the understanding of the database design and reduce the cost of any future modification and facilitates the knowledge requested by any developer or desginer
2- You should comment your columns if needed to be cleared what is this column functionality is . ( if columns are commented , the developer will know in very easy way what this column is designed to , and whic values allowed & which symbol means )
3- Naming Convention for database objects and its attributes should be kept to facilitate the work process and make any common adjustments can be done.( suppose that you keep the naming convention of your tables to be prefixed by 2 letter_ and the table primary key column is composed of your table name without the prefeix and suffixed by _id, you can create a stored procedure that create a sequence and trigger for any new table , so you can save the time and effort by keeping database objects naming conventions )
4- Documentation of the database design is very important for understanding, updating , and maintaining the database design , this document should describe the details of the database design and its functionality and break down ERDs .
5- The development environment must have maintained Templates for any developed business unit ( form – report - process - menue , ... etc) by having templates with subclassing you can adjust the code of specified triggers ( subclassed one ) of 1000 form module for example in 1 menutes after compiling the 1000 if you use object classing , or only one minute without compiling if you call the code stored in pll library ,
also templates are very critical issue in the development process or the interface changing .
6- Commenting the code should include the name of author
, the date of creation, the date of adjustment, the reason,
simple description of the functionality of the code. ,and hints on every line important to know
7- Testing Procedures must be set , starting with the unit test , transaction test to improve the quality of the product the process can be as the following :
- Test the business unit against (insert , update, delete, and query functions)
- Test the business unit against the required validation of the form or the report
- Test the functionality of the form or report against the functionality in the whole system cycle.
- Maintain more than one test scenario for the business unit .
8- Performance considerations must be taken to improve the quality of the product according to your frame work and your requirements , forexample
- Any SQL statement must be written on the database side not in the forms side to avoide the network traffic caused by the database roundtrips
- Any business unit must be developed from the designed template ( Form module from the from module template , report from the report template, parameter form from the parameter form template ,….. etc) to centeralize the performance tunning issues
- Packages Should be maintained and used in the Development process to get their benefits in performance and organizing the work
- Naming Conventions of the forms , reports ,PLL libraries , OLB libraries , Object groups , Program units , canvases, blocks, …. Etc must be maintained to easily develop and maintain (easy and fast )
- Any common Pl/sql code must be packaged in the PLL libraries to ensure that the right code is used for the issue arised
- Any common interface items packaging should be packaged in Object group (for example approval process , contact object group )
- Primary keys must be numbers only and auto filled not user filled other unique columns like code can have unique constraint and can maintained by the user
- No composite primary keys are allowed
- Use the appropriate way to get block non related data ( Join – view – database function ) according to the situation rather than using the post – query trigger
- Any in ordinary way of coding must be discussed between team member before using it in the development process ( discussion among the team member is very important and very usefull process )
- Any object group, templates, Should be documented and has its read me file to guide the developer how to use it in the development process.
- The basic triggers of the form or the report mustn’t be used by the developer ( instead write the code in the called procedures in the original triggers for example design your when-new-form-instance to call the following procedure - p_before_init ;
Fram_work_code;
p_after_init ;
p_before_init ; is module program unit that the user can write his code when he want to execute his own code in the when new form instance trigger , and so on .....
- Messaging to the end user must be done through defined package in the system to facilitate any future modification or enhancements ( like multilingual messaging)
- Any interface item ( text item , display item , list item , Button , ….. etc) must be sub classed from the appropriate object ( smart class shoul be maintained to easily do this process)
- Any tabular Block should have indicator item to improve the interface looking and current record visual attribute
- Any huge number of columns to be displayed on the form should be set its canvas to stack canvas style to expand horizontally.
9- “ Know How “ documentation must be maintained to facilitate the work process and exchange the experience between team members
10- The implementation of the work to the production Environment must have documented procedures and flow chart ( this is very important issue )
11- Documentation of how to develop Form Module, how to develop Report module, how to develop parameter form Must be read before any development starts for the first time , to avoid the violation of develompment standrds
No comments:
Post a Comment