ABAP CodeRetreat 20.5.2017 Vienna - Refactoring
•Download as POTX, PDF•
0 likes•494 views
Refactoring is changing the internal structure of code without changing its external behavior in order to improve various attributes of the software. It involves techniques like renaming variables and methods for clarity, extracting duplicate code into functions, and restructuring classes and modules to make the design and logic easier to understand. The key benefits of refactoring include improving code quality, maintainability and extensibility which allows adding new functionality more quickly.
Recommended
More Related Content
Similar to ABAP CodeRetreat 20.5.2017 Vienna - Refactoring
Similar to ABAP CodeRetreat 20.5.2017 Vienna - Refactoring (20)
More from Cadaxo GmbH
More from Cadaxo GmbH (20)
Recently uploaded
Recently uploaded (20)
ABAP CodeRetreat 20.5.2017 Vienna - Refactoring
- 2. @foessleitnerjRefactoring with ADT “The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet improves its internal structure.” What is Refactoring? Martin Fowler, Refactoring 1999 https://www.refactoring.com
- 3. @foessleitnerjRefactoring with ADT ISBN: 978-0201485677 Refactoring, by Martin Fowler
- 4. @foessleitnerjRefactoring with ADT Test Development Refactoring • Add a Test Make it work Make it clean Refactoring & TDD
- 5. @foessleitnerjRefactoring with ADT TDD Refactoring Refactoring ? Refactoring ? Refactoring Workflow of Refactoring ? Refactoring
- 6. @foessleitnerjRefactoring with ADT Workflow of Refactoring Just bad code!Litter-Pickup Refactoring ? Refactoring ? Refactoring TDD Refactoring Refactoring
- 7. @foessleitnerjRefactoring with ADT Workflow of Refactoring I don‘t understand Litter-Pickup Refactoring Comprehension Refactoring ? Refactoring TDD Refactoring Refactoring
- 8. @foessleitnerjRefactoring with ADT Workflow of Refactoring We should have done it this way Litter-Pickup Refactoring Comprehension Refactoring Preparatory Refactoring TDD Refactoring Refactoring
- 9. @foessleitnerjRefactoring with ADT Code Smells „stinkt“ (© Robert C. Martin) •Examples • Duplicates • Long methods • Big classes • Big case statements • Bad names • Misleading comments • …
- 10. @foessleitnerjRefactoring with ADT Example 1: Misleading comments * get all fields of BUT000 SELECT PARTNER, NAME1 FROM BUT000 INTO … * exit on error & FLAG <> ‘X‘ IF SY-SUBRC > 0 AND FLAG = ABAP_TRUE. EXIT. ENDIF.
- 11. @foessleitnerjRefactoring with ADT Example 2: Method name •What happens in the method • LR_DATE->ADD( 5 ) •Better • LR_DATE->ADDDAYSTO( 5 ) • LR_DATE->INCREASEBYDAYS( 5 )
- 13. @foessleitnerjRefactoring with ADT Code Quality Clean Code Profssionalism Right Thing Why Refactor?
- 14. @foessleitnerjRefactoring with ADT Why Refactor? Economy
- 15. @foessleitnerjRefactoring with ADT “We are doing this, to be able to deliver more functionality more quickly.” Martin Fowler, a pionier of the agile software development Why Refactor?
- 16. @foessleitnerjRefactoring with ADT https://twitter.com/foessleitnerj https://www.linkedin.com/in/johann-fößleitner-a9851b2a https://www.xing.com/profile/johann_foessleitner johann.foessleitner@cadaxo.com Thank you! https://twitter.com/domibiglsap https://www.linkedin.com/in/dominik-bigl-9b98b68b https://www.xing.com/profile/dominik_bigl dominik.bigl@cadaxo.com
Editor's Notes
- Im sure, most of you have heard about refactoring in the context of Test Driven Development
- You probably know this situation: You are looking into existing code, it‘s probably not yours, and you sad „O my good, tha‘ts realy bad code“. What was I (or the other developer) thinking? This is completely wrong! Martin Fowler calls such code „Yuck“ (=Igitt, Pfui, Pfui Teufel!) I startet my development careere 25 years ago. Back then we sad, if a code works - don‘t touch it! – If you touch it, you might brake it! - Remember „Never change a running system“ Btw: Funny fact, this pharses was only used in german-speaking countries. The Refactoring Mindeset says, when you see such bad code – you should fix it! – Maybee it was fine a year ago, when you wrote it. But now you realize, it‘s not right and you have to change it, you have to fix it. Martin Fowler describes this as Litter-Pickup! If you have read the Book “Clean Code” by Rober C. Martin then you have heard about the “Boyscout Rule”: If you have to change a code, always leave the code at least a little bit better. Make at least a small improvement! If you hit the code very often, then you will have a realy great code over the time.
- Sometimes you are looking into a code, and you do not understand what the code should do. „What the hell is this code doing?“ You have to analyze it, you have to go very deep into the coding to understand it. And then – I am sure you know the moment – you understand the Coding. „Bingo“ That is, what the code does! This is a important moment - but it‘s just in your head! For the moment. You can not share your brain with your team. And after a couple of months (or sometimes after a couple of hours) you have completely forgotten what the code should do. You should refactor the code to make it more clear, to make it easier to understand! Martin Fowler described this as Comprehension Refactoring Both Litter-Pickup Refactoring and Comprehension Refactoring requires the same reaction. There are 2 tracks, which you can consider: When ever you see something which you dont understand or is just bad code, you should ask yourself – „Do I wanna fix it now“. Is it a quick simple fix, or does fixing take a little bit of time. For example, if you just want to rename a method, then you can do it right now. But sometimes you have to think about the code. If you decide to fix it later, you should make a note – for example in the top area of you code – and as soon if you have finish your regular work, go back and make it a little bit cleaner.
- I am sure you know the situation: You look into some code and you realize, I have new insights how the code should work, that I didn‘t have bevore. Especialy in the context of adding a new feature. You have to add some new functionality to put in, and it whould be realy easy to add this new function – if the existing code was organized a little bit different. Maybe the code was o.k. when you have developed it, but now you have to add new features and it‘s not looking right anymore. This situation is called „Preparatory Refactoring“ Basically this means, before you add a new function to an existing coding which not fits in a shape that you want, refactor it! Refactor it, make the tests until they are green – and then start to add the new feature to the better refactored code base. Some people think, that refactoring slows you down, that refactoring blocks your time from other things. Usually the benefits from refactoring results in the medium term. But in this case, you can get that benefit right now in the middle of the task you are doing. Often it is faster, to do a preparatory refactoring and then add the new functionalty.
- People often talk about refactoring, „Why should we refactor?“ – Because we want have a good code, a clean code. Because it is the „Right Thing“. If you use these arguments in discussions with your customers, you have lost.
- The only valid argument is economy!
- We do this, to deliver more functionality more quickly! This is the only reason!
- We do this, to deliver more functionality more quickly! This is the only reason!