Improving the Quality of ABAP Code, 1st ed. Striving for Perfection

Gain an in-depth understanding of the large number of common problems found in ABAP programs and have a robust methodology for fixing problems when you find them. This book also shows you how to prevent them from occurring in new programs.

A large chunk of the world?s biggest organizations use SAP software and virtually all of them have very large amounts of custom code. However, a lot of that custom code is not as good as it could be. In this book we look at why object-oriented programming is the basic building block for improved program quality and at the test-driven development that this enables. We cover the three pillars of clarity, stability, and high performance on which a high-quality ABAP program stands. You will then move on to the user interface, which needs its own set of standards for high quality. In the final chapters, you will learn about specialist topics such as user exits, making sure code will run on the latest releases of SAP, and how to add your own automated custom code quality checks.

What You Will Learn

• Know why object-oriented programming and test-driven development are the cornerstones of high-quality custom code
• Ensure that the three pillars of clarity, stability, and high performance are fulfilled
• Make sure your applications are user friendly
• Ensure that your custom code works on newer SAP releases
  
• Create your own custom code quality checks

ABAP developers who started yesterday or have been programming for 20 years

Chapter Goal: This chapter explains the practical (as opposed to theoretical) benefits Object Orientated(OO) programming can bring the reader, and why it is a must to really improve your code quality.

Chapter Goal: This chapter explains to the reader the very real benefit this approach can bring to the quality of your code, and how TDD could be viewed as being more about code quality than testing. The next three chapters in fact comprise the “Blue Phase” of TDD.

Chapter Goal: This chapter and the next two first explain some theoretical concepts about an area of code quality, and then demonstrate the practical benefit to the reader of following that theory with a large number of real-world examples. This chapter deals with the concept of clarity which many programmers attach zero importance to, not realizing they are shooting themselves in the foot.

Chapter Goal: This chapter shows the reader how stability problems can be caught by tests, and how to make programs “fault tolerant” - an area which is often ignored.

Chapter Goal: In this chapter the reader learns how once the code is clear and correct how to make it run as fast as possible by highlighting dozens of common performance traps in code that programmers often fall into.

Chapter Goal: In this chapter the reader will learn how to increase the quality of the Ui regardless of the technology used, and as with the previous chapters a large number of concrete examples will be shown.

Chapter Goal: In this chapter the reader learns the safest way to approach this task and how to ensure the robustness of the custom code in the user exit and how to prevent it breaking the behaviour of the surrounding standard SAP code.

Chapter Goal: In the past SAP ensured that ABAP code was always 100% downward compatible so that after an upgrade to a new version your custom code always kept working. This is not the case when moving to S/4HANA as it is in effect a totally new product. In this chapter the reader will learn how to ensure their custom code is of a high enough quality to keep working after a move to S/4HANA.

Chapter Goal: In this chapter the reader will learn why that is the case and how to ensure their code is structured in such a way that when and if the time comes the changes they will need to their custom code will be as painless as possible.

Chapter Goal: SAP provides some fantastic tools for automated static code checking, the most prominent of which is the ATC (ABAP test Cockpit). However, there are bound to be things that any given organization needs to check for which are 100% specific to their needs. Such checks will not be in the standard so in this chapter the reader will learn how to code such checks themselves and have them seamlessly integrate with the standard SAP ATC tool.

Paul Hardy joined Heidelberg Cement in the UK in 1990. For the first seven years, he worked as an accountant. In 1997, a global SAP rollout came along and he jumped on board and has never looked back. He has worked on country-specific SAP implementations in the United Kingdom, Germany, Israel, and Australia.

After starting off as a business analyst configuring the good old IMG, Paul swiftly moved on to the wonderful world of ABAP programming. After the initial run of data conversion programs, ALV reports, interactive Dynpro screens, and SAPscript forms, he yearned for something more and since then has been eagerly investigating each new technology as it comes out, which culminated in him writing the book, ABAP to the Future.

Paul became an SAP Mentor in March 2017 and can regularly be found blogging on the SAP Community site and presenting at SAP conferences in Australia (Mastering SAP Technology and the SAP Australian User Group annual conference) and at SAP TECHED Las Vegas. If you happen to be at one of these conferences, Paul invites you to come and have a drink with him at the networking event in the evening and to ask him the most difficult questions you can think of, preferably about SAP.

Based on real-world examples rather than academic theory

Teaches why the problems are bad rather than just saying how to fix them

Covers a subject of interest to every ABAP programmer