Clean ABAP is the ABAP implementation of Clean code. Clean code is one of the key principles to adhere to when going Agile. Clean code is part of agile software development craftmanship. Read more on clean code in the original book.
Clean ABAP reference site
Clean ABAP is published and maintained on a dedicated Clean ABAP Github site.
The site itself is excellent and also has a special chapter how to best start with Clean ABAP.
The site is extensive and might be overwhelming. If you are a more traditional person, you can also read the SAP Press book on Clean ABAP code.
Patterns and anti-patterns
The Clean ABAP explanation on the site contains both patterns (how you should do) and anti-patterns (how you should not do).
Anyhow the Clean ABAP principles are fully built on Object Orientation. That is a must.
Introducing Clean ABAP in your organization
Regardless if your organization is doing Agile or Waterfall development, or other development methodologies, Clean ABAP can be applied anyhow.
First step is to embrace the Clean ABAP as a principle direction. It will take time to get there. Not all developers will pick up as fast as you might want to. It also takes time to refactor old code to the Clean ABAP principles.
Discuss as developers as a team which part of the principles and improvements you want to pick up first. If you master a few, you can make it mandatory. Then take the next set. Some might pick up more at a higher pace. But keep the discussion going to improve and pick up every 2 weeks (sprint) at least 1 improvement item.
For a nice overview: read this SAP blog.
Peer review or pair programming: ATC variant
You can make the Clean ABAP code rules a part of your peer review or pair programming.
There is an ATC variant that can be uploaded that check for the clean ABAP code rules.
Boy Scout rule
The boy scout rule is as follows: leave the place nicer than when you arrived, even though you didn’t make the mess. When you do this repetitively the world becomes a cleaner place.
This also applies to poor code: don’t just do your change, but take along some minor improvements as well. When you do this a couple of times, the poor code will improve every time towards good code.
But this principle you also need to embrace and explain. There might be unlucky situations where the clean up part might cause unexpected bug. This might happen in 0.01% of the cases. When it happens you might get resistance and pushback. But stand up for the principle, and simply correct the bug. It is worth it in the long run.