People think there isn’t a code review tool for ABAP. It turns out you can do that with abapGit.
abapGit is an open-source git client for ABAP. It serializes source code and data dictionary elements to plain text, so that they can be persisted in a git repository.
An example of a serialized class
With this serialized code you can leverage Git services, such as GitHub or GitLab, to create Pull Requests. Think of a Pull Request like an SAP note, where you can see the code differences and the reason for the change.
Then, with GitHub, you can create code reviews for it, like on the image below:
A pull request review in an abapGit repository
Although abapGit connects to an online repository, in our approach we use another functionality: you can export all serialized code to a zip file (or even export a transport request contents). We use that to manually commit the differences.
The programmer has in its computer a folder with the serialized code. Then, she manually commits the change and pushes to the online repository. We do because using branches at ABAP would be confusing, since this concept does not exist.
Next you will find a detailed story on how we, at IBSO Engineering Latin America, do this.
Eliza is finishing the development of a user story in this sprint. One of her team’s definition of done rules is to have a code review. This code change is not so big: some new code in a class along with its unit tests. She also did a refactoring on some parts.
She starts the GitHub Flow. She goes to the cloned repository in her PC, and runs a git pull to get the latest version from the repository. Next, she exports all project contents to a zip file. She creates a new branch and extract the files which she made the changes. She commits the changes, and push to the online GitHub project repository.
There, she opens a Pull Request and assign Daniel to review her code, which he starts right away.
The first thing Daniel notices is the Jenkins build is failing. Every new pull requests triggers an automatic job with the new source code. This time, there are abaplint warnings she should fix. Also, Daniel points out that there is a missing unit test and, in some points, the coding conventions were not followed. Daniel marks the review as “Request changes”.
Eliza fixes the code review findings, and submit a new version. If Daniel had not marked “request changes”, she would not need to do this. Daniel reviews the code again, and approves the Pull Request.
Just try it
This practice require little effort to put in place and generates a great return. You will bring the benefits of code review to your team: knowledge sharing (both technical and functional) and code quality (make it easier to introduce new features and fix bugs). I suggest you try it and see the effects for yourself. If you have any question, leave a comment!