Code Quality? Of course, I always build my things well. Everyone should be able to work with it, so no unnecessary authorization checks. Comprehensive testing? You can always do it later. Finish it first. Follow the guidelines? I’m working on it. Whenever I have the time, but unfortunately, we’re often in a hurry… I’ll submit the documentation later; nobody needs it at the moment anyway. F4 help? Yes… that’s right. That would probably be good. But on the other hand – only people who know what to enter in the mandatory input field P_DODEL work with it anyway. (Day of Delivery is!)
Everyone knows that. “Code quality? Totally important! But…”
This blog post is intended to help developers and product managers to get to know the purpose of code reviews and some of the points they can bring.
Because what about the problems that unreviewed development can cause?
Quite simply: the development does not do what it is supposed to, is not efficient and not secure, offers neither help nor documentation, is poorly structured,
Consequence: such developments are neither easy to use nor easy to maintain but are prone to errors and problems. This may result in further considerable costs. That is why they are also expensive! And in the end, nobody is satisfied, not even the developers, but especially not the customers!
A code review, which must take place before an “official test phase” at the latest, helps everyone involved to check software developments in terms of quality and security and to optimize them if necessary, in order to reach a better, safer solution overall – and to achieve a learning effect for everyone involved.
Ideally, a code review will get faster each time, for example as problematic constructs are identified and not reused over and over again and as the guidelines become increasingly internalized.
The purpose and aim of Code-Reviews
Threat-Modeling As I have already written in my last blog post
The aim of testing in software development is always to ensure the availability, reliability and confidentiality of the system. These three principles must not be compromised by any software development or application.
Therefore, new developments or their code sections must be carefully checked to ensure that they do not compromise these principles.
Specific intentions, questions, implementation:
- Improvement through working together
Every developer should experience or request a code review at least once a year.
- Improvement through code explanation
Programs and code that you show and explain to others are viewed differently in that moment. At this point, the question has already been answered: Does the code do what it should?
- Improvement through listening
The reviewers can say what is perhaps missing and can be done better
- Improvement through common standards
Have the guidelines been followed (for internal and external developments)? Is the code clear?
- Improvement through performance measures
Statements about performance can be made from the code if certain constructs and procedures are observed.
- Example 1: No Select * from [dbtab], only the required fields and no repeated identical selects, but READ from [itab]
- Example 2: Application of the PUSH-DOWN procedure by using CDS views
- Generally, when running in a system with realistic data: Run and analyse performance trace
- Improvement through better description Is there documentation and are input fields provided with [F1] and [F4] help?
- Improvement through more security
Are authorization checks planned, for example? Are maintenance views linked to a table authorization group so that not everyone can change data?
- Improvement through tests and error handling
Are the test results of formalized tests OK? => At least no errors with priority 1 in the tools “Extended Syntax Check (SLIN), ABAP Test Cockpit (ATC) or Code Inspector (CI)? Are unit tests available?
Code Review: What is considered?
Here is an overview of the checklist of the Inwerken developer group’s code review template.
Pay attention to Resources
It should also be mentioned that the functionality must generally be checked for security and to ensure that it does not consume too many SAP system resources. If a query is technically correct but finds too many result sets, it can potentially affect the system. The response times are then too long, or the system no longer responds at all. If, for example, too much memory is used or too many locks are set and held, other users are hindered.
Results of a code review
At the end of a code review with a checklist, there is ideally an OK for the code quality of the development or a list of measures is decided that are carried out by the developer to improve the code quality and checked by reviewers.
In summary:
A code review in software development should do its part to meet the most important requirements of development: appropriateness, compliance with specified guidelines and safety standards, readability and maintainability of the code.
It does this by following the approach described above to reviewing software development and enables the discussion of general quality and safety standards from different areas.
The aim is always to achieve the greatest possible code quality within a framework appropriate to the current development. Customer satisfaction and cost-effectiveness must be taken into account – although customer satisfaction can also lead to new projects, which is why it should be given higher priority.
