Copyright 2024 - BV TallVision IT

The overhaul

Would you like to know how much work is involved to make sure any given (custom) development is overhauled ? An overhaul is a series of development improvements that should bring a development to a quality assured level. Data integrity, performance tuning and the avoidance of hard-coding are the main targets for an overhaul. The exact details of the overhaul can be defined according to the programming conventions on your project. This overview outlines the main subjects that should be covered:

1. Copy the program you would like to overhaul (along with all it's includes), e.g. use a naming convention with names ending with _OVERHAUL or _HAULCOPY. The idea is that the overhauled version of a program can be compared to the original version - which allows spotting differences. Normally the "safety copy" doesn't need to leave the development system, however if the development system doesn't have proper test data, putting the copied programs through the system landscape is an option. Better put the message "This is an OBSOLETE version of ..." on the reports.
2. Address the Code Inspector issues (program check instead of Code Inspector for versions before 4.7) - Which includes solving all the errors and minimize the warnings. Make sure there's no select single statements that don't have a full key, check the SY-SUBRC after every select statement or function module call that returns exceptions. The variables that are not used can all be removed. And while you're at it - find the globally defined variables that are used locally within form routines, and move the global definition to the routine. Any unused routines - simply remove (after checking external calls with the where-used list).
3. Dead comments removal The program will most likely have a header with a log of changes. Also within the code, references to changes will be available. Since the overhaul is in a way a fresh start - the change log is regarded a burden: remove it all and remove commented out coding as well. Only if a comment block describes functionality clearly it can remain. It's up to the overhaul developer to determine whether given comments still hold value after the overhaul is completed. Generally: comments from the change log usually don't survive an overhaul. And while you're at it: put a standard looking comment block in place which clearly states an overhaul has been done. You may want to mention the copied program here as well (available only on development).
4. Performance tuning (database) Walk through the performance tuning steps. In a nutshell:
  1. Avoid nested SELECT statements
  2. Select within a loop: never put a SELECT statement in a loop
  3. Use SELECT INTO TABLE and FOR ALL ENTRIES where possible
  4. Specify field names in your SELECT statement
  5. Keep select statements grouped together
  6. Utilize indexes
5. Authorization checks should be set up. Make sure the checks apply when a report is triggered via it's own transaction code as well as via SE38 or SA38. Make sure the program is stopped with a clear message on authorization.
6. Attack hardcoding hard-coding values in a program should be avoided as much as possible. There's an article on hard-coding in this issue (see link at the end of the article).
7. Locking check Ensure Locking for table updates (and deletes and inserts) are checked. Also make sure the enqueue locks that were set remain set. When e.g. a COMMIT WORK. is done, the locks could be released. On locking errors, ensure the user that is locking the requested object shows in the message ("Object is locked by SOMEONE").
8. Mass updates check If there is a big number of updates (or creates) to be done - make sure the total number of updates between COMMIT WORK. is limited (e.g. a COMMIT WORK. for every 20 changes)
9. The program skeleton The program will have a set of routines or methods which are there to process a task. If such routine/method is only called once - it should earn it's right to exist. The names should reflect what they are doing and passing parameters should be done properly. Routines should be using USING as well as CHANGING instead of only USING. Form routines that work on (change) global variables should be avoided as much as possible and if not this is where the routine comment block can clarify things. Is the START-OF-SELECTION event filled with a huge block of code ? Move to a (or several) form routines or methods. Found one with over than 150 (guideline figure) lines ? Find a logical purpose for part of the coding and introduce a new routine/method.

Even though SAP Abap supports routines and methods in the same source coding, the developer should "pick a side". With an overhaul routines are likely to be available - so should classes/methods be introduced ? Yes they should ! Any new coding should be set up in Object Oriented Abap!
10. Minors. Focusing on "the minors" can make a big difference and all comes down to the developers common sense. A few examples to put this calculation step in the right frame of mind:
  • The program and its includes should have names according to the naming convention. This also applies to variable names in the program
  • Where possible, reading internal tables should be done with the BINARY SEARCH option (ABAP performance tuning instead of database tuning)
  • The names of routines start off with a name which should indicate what the routine is for. In the mean time, this routine name should be redetermined ?
  • Does a part of coding look complicated ? Work out what it does and check if it can be coded in a simplified manner
  • A deep set of nested IF statements ? Turn into something more readable
  • Describe table lines to find out whether there are entries in an internal table ? Use I_TABNAME[] IS INITIAL instead (and remove the variable used for the line counter)
  • Are fields being cleared after the fact instead of before starting ? Initialize is an action that should be done before anything else
Home   System health   The overhaul