Stored procedures/functions are required for all Database access (server side). Client side coding is kept to a minimum and only used if approved by Application Architect and Business Systems Analyst. This is a security measure used to prevent infusion attacks.
Adaptable to cope with changing requirements. The following questions will help judge the maintainability code:
- Can I find the code that is related to a specific problem or change?
- Can I understand the code? Can I explain the rationale behind it to someone else?
- Is it easy to change the code? Is it easy for me to determine what I need to change?
- Can I make a change with only a low risk of breaking existing features?
- If I do break something, is it quick and easy to detect and diagnose the problem?
- Does the code meet its specification, i.e., "correct output for each possible input"
- Is the program efficient enough for the environment in which it is used?
Ensure that the code is user-friendly and intuitive, allowing users to interact with it easily and effectively. This includes:
- Clear documentation
- Meaningful error messages
- Interfaces that are intuitive and easy to navigate
- Prioritize simplicity and clarity while writing code
- Name of the module
- Purpose of the module
- Brief description of the module
- Original author
- Original implementation date
- Change control list which identifies:
- Date of change
- Who authored the change
- Footprint ticket or project number that initiated the request for change
- Description of change
- Sample execute statement
- In-line comment of variables at declaration to identify purpose and use
- In-line comment blocks to describe required functionality for code when logic is complicated or more involved than usual.
- This adds to maintainability, allowing others to quickly understand what is happening in the logic.
- Create / update unit tests documentation (at minimum) for modules/ features.
- Create / update help documentation associated with the change to the module/ feature.
- Create / update technical documentation associated with the change to the module/ feature.
- Naming conventions must be adhered to.
- Code portability is a goal. Hard-coding is to be avoided whenever possible (it is recognized that in some cases this is unavoidable).
- Should hard-coding be unavoidable, it must be identified and reviewed with the Business Analyst for approval.
- The approval must be documented as part of the project documentation.
- All development must complete a code walkthrough prior to being promoted to QA/Production.
- Walkthroughs should include: BSA and a Team Lead. DBAS should be included for complex SQL or when processing times need to be reviewed.
*Hard coding = fix (data or parameters) in a program in such a way that they cannot be altered without modifying the program.
*BSA = Business systems analysts
*DBAS = Database Administrator
- ⬜ Does every input that comes from an untrusted source (i.e., typing into fields on a page, external systems) have associated error checking accounted for?
- ⬜ Are all forms of validation done on the server side? (only allow on the client side on an as needed basis)
- ⬜ Stored procedures used as the method for data validation/delivery
- ⬜ Is each coding module of sufficient size? Limit the size for readability and maintainability. Use a 4 page rule of thumb. If the module is larger than 4 pages consider if it can be reduced in size or functionality can be split out; also consider the following:
- ◻️ Size and quantity of data that would need to be passed between routines
- ◻️ Number of temporary tables that would be needed
- ◻️ Any extra database reads/writes that would be required
- ⬜ Does the code have the following:
- ◻️ Proper naming convention
- ◻️ Purpose is documented
- ◻️ Brief description
- ⬜ Original author and date are identified
- ⬜ Change control area showing date of change, reason, person who did it and associated project or ticket number
- ⬜ Sample execute
- ⬜ Unit test documented and repeatable
- ⬜ Sufficient commenting exists throughout the code to make it readable and understandable (i.e., maintainable) and the comments match the actual code.