Secure Software Development Management & Guidelines

This page outlines Vertic’s standards and guidelines when software development in undertaken. This is a critical function which is principally closely aligned to the vendor guidelines we have partnerships with.

Security

This section is fundamental to ensure the code is not vulnerable. It highlights standards related with ensuring proper access to functionality and data as well as preventing hacks, including the following:

• Always using “with sharing” in Apex Classes except when strictly necessary

• Sanitise all user inputs used in queries to avoid SOQL injection

• Enforce field level security when displaying records queried using Apex to an end user.

• Avoid the global modifier

Code Modularity

The goal for this section is to ensure that code is not overly complex and is readable, reusable and maintainable. This includes standards such as the following:

• Recommended max size of methods or classes

• Number of allowed nested if or for clauses.

• Number of variables or fields in a class

• Avoiding duplicate code and abstract functionality in its own method

Performance

The goal for this section is to ensure code runs efficiently. This includes standards such as the following:

• Avoid costly operations in loops (e.g. queries)

• Leverage list iterators when dealing with large volumes of records

• Do not have unused instructions or unnecessary debug statements in production code

Readability/Style

This section includes general best practices to make the code more readable like:

• Naming conventions for variables, classes, methods…

• Instructions to name entities in a self-descriptive manner so their purpose is obvious

• Guidelines for proper use of brackets, parentheses, method parameters

• Guidelines for maximum line size

Patterns and Frameworks

This section can be divided into multiple sub-sections. It has more impact on your development standards than any other section and includes the rules on how to develop at Vertic beyond instruction level details.

This section can include general best practices like:

• Do not have logic inside of a trigger

• Leverage try-catch statements in riskier operations and ensure exceptions are graciously handled

• Do not hardcode Salesforce Ids

• Leverage custom settings and metadata types for your configuration data

More importantly, the guidelines in this section can also instruct on how to use patterns and frameworks that Vertic defines as standards and wants implemented across all the applications. Trigger framework to control trigger logic

• DML framework to efficiently control database executions and its exceptions

• Error Handling framework to standardise error logging and notifications

• Test factory framework to standardise data creation for unit tests

• Service Layer pattern for object specific operations

• Domain Model Layer to encapsulate queries to the database

Naming Conventions

Naming conventions are a fundamental and often overlooked part of development standards. They ensure the ease of locating related functionality associated with a specific feature and help developers navigate a Salesforce implementation containing multiple applications and business units. Within code, they mostly apply to class or component names, but this section can extend to configuration elements too.

Some of the conventions are common practice like appending “Batch” to batch classes, “Test” to unit test classes or “Ctrl” to controller classes. Some can be specific to Vertic like prefixing the application name in all metadata (when a namespace is not used) or the name of a specific framework (e.g. TDTM) in all the classes leveraging it.

Naming conventions is frequently something that spreads across multiple sections of the development standards and it’s not its own self contained section since it is part of styling, patterns, testing, and others.

Testing Requirements

Standards around how to write Salesforce unit tests include:

• Have positive and negative use cases

• Test bulkified scenarios

• Include assertions and error messages in all tests

• Create test data (using our approved test data creation site)

Standards around what to test typically include:

• Tools to test Apex code

• Tools to test Lightning Components

• Tools to test integrations

• Selenium tests if they exist

• Testing triggers

• What doesn’t need to be tested (e.g. model classes, standard functionality)

It’s important to ensure that your testing goes beyond simply testing backend code. Salesforce enforces 75% code coverage in Apex code but it is fundamental to address unit testing of front end code as well as automated testing scripts for both code and configuration.

Documentation Requirements

The goal of this section is not to define how to document a specific application but rather how to document within Vertic’s code, including:

• Leverage the description fields when creating metadata Use tools like ApexDoc or JSDoc to automatically generate coding documentation

• Track authorship and date changes within code

• Determine when and how much to comment in code (this is a very polemic and divisive issue)

Manual Code Review

Vertic’s SDLC (Software Development Life Cycle) includes backing up code to a shared repository (GitHub). Tools like these not only back up your code and configuration metadata, they also offer a raft of other features as well. For example, a developer can request a code review right in the tool where another developer can look at highlighted changes to the codebase and verify that the changes make sense to accomplish what was needed and uphold your standards.

Even though it is a time-consuming and manual process, code reviews offer even more benefits for understandable code. In a code review, an experienced developer reads code and offers constructive feedback to improve the code based on internal standards as well as knowledge of platform and organisational best practices.

Manual code reviews can also be run like a technical handoff where one team member shares the design decisions and technical details of a solution with another team member who can request improvements. These can also be run between two teams working in the same Salesforce org.

The maintainability benefits of manually reviewing code make it worthwhile to spend time ensuring that the experience is uplifting and positive for developers, something they look forward to and agree is beneficial for all. In order to reach code review nirvana, set rules of engagement for all manual code reviews and establish what the intent is:

• Mutual code improvements

• Knowledge transfers

• Security enforcement verification

• Team building communications

Rules of engagement should also establish a timeframe so that code is not held up by reviewers. In addition, you can define when changes are complex enough to require a demo and walkthrough of the solution, which can be incorporated into sprint review in mature Agile workplaces.

Not all code changes are that complicated. Sometimes, a well understood section of code can be refactored to take advantage of platform improvements or to be made more reusable. In these situations, there may not be a need for a demo and developers can use a shared repository to get insight into changes and review them online with written feedback for a quick turnaround.

Whether feedback is offered in person or in writing, rules of engagement clarify what the reviewer should prioritize investigating and how to communicate changes that must be made vs changes that could be made. Some reviews uncover security or performance issues that prevent code from moving to the next environment and can be noted with keywords to call out the requirements. There may be high impact suggestions like refactoring to make code more reusable.

Other reviews may only find more stylistic considerations to improve readability that could be fixed in a future refactor rather than holding up a project. For the latter, consider using “POP” to denote “Point of Polish” feedback. For the former, high impact suggestions, consider “HI” as a shorthand way to note “High Impact” feedback.

Good governance with carefully planned use of automated tools and well curated feedback improves your CI/CD process, fosters growth and teamwork, and enables developers to provide even better products for end users. As enforcing standards and communicating becomes a habit for your development teams, time-to-delivery and release errors both should decline. And the number of developers with skills and knowledge to improve code should increase.