Are you familiar with the concept of “sense of code”? Just as a musician needs to have a sense of rhythm, a developer should have a sense of code. Each developer should improve it during their career. Usually, it is directly related to experience and knowledge, and every pull request improves your sense of code, even if you are a submitter.
Code review is an endless source of ideas, both good and bad. You have an excellent chance to know where the project is going and to influence it. The main goal of code review is to improve the quality of software by detecting and fixing errors and problems at an early stage of development. Code review can also help exchange knowledge and experience between team members, leading to an increase in competence and work efficiency.
Code Quality Attributes
Before we find the answer to how to complete a successful code review, we need to understand the main attributes of good code. This helps us to structurize the review process.
The development process requires us to read the code most of the time, so our code should be easy to read. How to make code readable is a popular topic, with plenty of resources out there to explore.
Formatting and assigning proper names for classes, methods, and variables will help us immensely, and avoiding complex structures and endlessly nested operations can also be beneficial.
What is the difference between readability and clarity? Well, think of it this way: just because you can read code doesn’t mean you can understand it.
The most common problem with code clarity is mixing abstractions; low-level operations (looping collections, conditions, assignments, etc.) are used in high-level class methods (for example, in controllers).
Of course, our code should be reliable. This includes error handling, limit checking, operation timeouts, logging, self-recovery after failures, and transaction control. Some patterns can help you to solve most of these issues.
Reusability and Extensibility
Code is not something immutable and is often overridden and extended. Know that you should always think of the future; the possibility of changing code is very high and should be applied during development. Moreover, this will help you avoid duplication.
Don’t be afraid to break up your code on classes and methods, and don’t forget to use OOP. If you don’t do this, it may be too risky and difficult in the future.
Have you ever said, “This code cannot be tested”? Sometimes it is out of our control because of platform limitations, but usually, it fully depends on the design we choose. Try to consider it during the development code. Of course, I recommend using TDD in any form you can.
There are no ideal systems. No matter how well we test our application, unpredictable bugs are inevitable. All we can do is minimize their appearance, log them correctly, and use approaches to stabilize the system after a crash.
Efficiency and Performance
Different systems have different performance requirements, but in any case, always ask yourself, “What if?” Best practices in Salesforce and common sense will help us avoid performance issues.
The project code should always comply with security standards and be protected from attacks. Much of this can be covered by the best Salesforce practices we know.
In addition, keep track of the versions of third-party libraries and use automated checking tools. Consider a secure connection if you need to build third-party system integration. Salesforce has a lot of great tools to achieve its safety (auth provider, connected applications, named credentials, etc.).
Code Review Process Tips
We have now identified the main criteria for good code. So, how do we apply them in practice?
Don’t jump into everything at once – it can quickly become overwhelming. Like everything in development, the code review process should be broken down into sections and followed in order. The following points will help you make the code review structured, and it is recommended to make a checklist.
Understanding the business goal that the code covers is very important before you start the review. Often, perfectly written code does not fully cover the requirements, or it does, but with side effects. Therefore, you have to know exactly what the code should do.
There is a high probability that someone has already solved your task, so do not hesitate to suggest existing solutions. Finding a ready-made solution can reduce risks and save a lot of time. Remember that ready solutions are much cheaper.
- Ensure there is no applicable functionality within the Salesforce platform. Salesforce has a lot of functionality, and sometimes the lack of experience forces us to create custom solutions.
- Check if there is a ready-made package available on the AppExchange. I had an experience where developers recreated the solution, which I then installed for free.
- Customer success is our goal. Saving money and time for customers means improving loyalty. Discuss it with stakeholders even if the suggested solution doesn’t fully satisfy requirements.
- GitHub is an incredible platform where you can find open-source solutions. Don’t forget that solutions from GitHub also need to be reviewed. Pay attention to the solution’s license to avoid an unpleasant situation after release.
Design and Architecture
Pay attention to the structure of the new components and their dependencies. It’s time to pay attention to the already familiar clarity, reusability, extensibility, and testability. For projects with a managed package, this item is highly important since it is very difficult to remove new classes from the package after release. Follow SOLID principles and use patterns.
Pull Request Comments
An important part of the review is the comments. Their quality and quantity affect the speed of reviews and development.
For the Reviewer
- Comments must be meaningful. Like code, comments should be simple and clear.
- Write comments as a question if you doubt your decision.
- Don’t leave the same type of comments. This will help you understand how responsive the submitter is. If the problem persists, it is a marker to talk to them and point to their mistakes.
For the Submitter
- Files that are difficult to read should be commented on, and screenshots can be attached (metadata, Flow, etc.).
- Explain non-obvious logic or actions (don’t forget self-documented code).
- Do not comment on obvious things. It reduces the review time.
Avoiding large pull requests can speed up the review process. A versioning system can help break down a large task into smaller commits or separate pull requests. I am sure all developers are happy when the pull requests are approved and completed, so try to save the reviewers time.
Code Analysis Tools
Code analysis tools are actively developed like everything else, and they are divided into types and functionality. Using pull request validation can simplify a lot of things. Good practice of automatic pull request validations is code coverage validation. I recommended sticking close to 90% of code coverage even though Salesforce requires us to have at least 75%.
I highly recommend you take a look at Salesforce Graph Engine – the newest engine to join Code Analyzer’s backend. It performs DFA on Apex and identifies issues of much higher complexity than a regular static analysis engine. Even if it has some issues with stability, I expect it will be a main tool for Salesforce developers.
AI has also become more popular in the Code Review processes. Based on webinars, the Salesforce team is actively working on including AI in code analysis tools.
The code review process plays a critical role in the life of a developer. By following the tips outlined in the article, developers can make the process more efficient and effective. A good code review is closely tied to the architecture of the project, which ultimately impacts its overall comprehensibility. As developers engage in code review, it is important to remember key attributes of quality code, such as readability, clarity, reliability, reusability, testability, maintainability, efficiency, performance, and security.
By prioritizing these attributes, developers can ensure that their code is of high quality and can be easily understood and maintained by other team members.