![132
Automated testing
Integration tests are a scam
Pairwise testing
Why most unit testing is waste
Technical debts
Managing technical debts (1)
Technical debts with sonar
Managing techincal debt (2)
Books
Working effectively with legacy code [Michael C. Feathers]
The pragmatic programmer [Andrew Hunt, David Thomas]
Refactoring: improving the design of existing code. [Martin Fowler]
Clean Code [Robert C. Martin]
Further reading](https://image.slidesharecdn.com/refactoringworkshopv2-160331102218/75/Refactoring-workshop-132-2048.jpg)
More Related Content
![[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...](https://cdn.slidesharecdn.com/ss_thumbnails/christophek-180419103038-thumbnail.jpg?width=640&height=640&fit=bounds)
Refactoring workshop
- 1.
- 2. About me 2 • ItzikSaban • A software developer since 2000 • B.A. in computer science (Open University) • Agile programming mentor – TDD, Clean Code, Refactoring, Continuous integration, etc. • Part-time entrepreneur • Co-organizer of the Clean-Code-Alliance at meetup.com
- 3.
- 4. Objectives 4 • To understandthe importance of refactoring. • To acquire skills to do a day-to-day refactoring. • To learn techniques to deal effectively with legacy code. • To acquire skills to deal effectively with large scale refactoring operations
- 5.
- 6.
- 7. 7 As a systemevolves, its complexity increases unless work is done to maintain or reduce it. Lehman’s law - increasing complexity
- 8. 8 The act ofimproving design without changing its behavior is called refactoring. What is refactoring?
- 9. 9 When to refactor? •Fixing a bug. • Adding a feature. • The boy scout rule. • Paying back technical debts.
- 10.
- 11. What is atechnical debt? 11 You need to make a change. You do it smart and clean. You do it quick and dirty. This will make future changes very hard This will take you longer
- 12. 12 Every time youare compromising about your code, you are creating a technical debt. A technical debt is very similar to a financial debt: • The principal amount is the cost of refactoring to a cleaner design. • The interest is the extra costs, which have to be paid in future changes. What is a technical debt?
- 13. 13 Like financial debt,Technical Debt is not necessarily a bad thing. Sometimes you create debts to leverage your business: • First to market. • Fines on delays. • Special opportunities (black Friday for example) But, if you are accumulating debts, eventually the interest will take you down. Is technical debt a bad thing?
- 14. 14 In average applicationscarry a debt of 3.6$ per line of code, per year! (Given by CAST - the world leader in software analysis and measurement) Technical debts – what’s the cost?
- 15.
- 16. 16 You are nottruly free until you are debt free! Your code should be constantly refactored. Technical debts
- 17.
- 18. 18 IDE refactoring Your IDEprovides a plenty of refactoring operations that are more safe and easy to use. Using these operations will improve your code constantly. A craftsman programmer MUST know her/his IDE very well.
- 19. 19 Rename )class/method/variable) Motivation: When thename of a class/method/variable does not reveal its purpose. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” (Martin Fowler) IDE refactoring
- 20. 20 Rename )class/method/variable) Stand onthe element you wish to rename and press Shift+F6 IDE refactoring
- 21. 21 Rename – publishedinterface If a class/method/field is being used by external projects (as a .jar or as a .dll) it becomes published (a step beyond a public) To change a published interface, you have to retain both the old interface and the new one, at least until your users have had a chance to react to the change. IDE refactoring
- 22. 22 Generate getters andsetters Stand anywhere on the class and press Alt+Insert IDE refactoring
- 23. 23 Introduce Explaining Variable Motivation: Youhave a complicated expression. Put the result of the expression, or parts of the expression, in a temporary variable with a name that explains the purpose. IDE refactoring
- 24. 24 Introduce Explaining Variable IDErefactoring
- 25. 25 Introduce Explaining Variable Selectan expression and press CTRL+ALT+V IDE refactoring
- 26. 26 Extract method Motivation: Small, welldefined and well named methods are preferred. Also useful to remove code duplications IDE refactoring
- 27. 27 Extract method (example) IDErefactoring
- 28. 28 Extract method (example) IDErefactoring
- 29. 29 Extract method Select ablock and press CTRL+ALT+M IDE refactoring
- 30. 30 Introduce Parameter Object Youhave a group of parameters that naturally go together. Replace them with an object. IDE refactoring
- 31. 31 Introduce Parameter Object Motivation: •Long parameter lists are hard to understand • Pretty soon you see behavior that you can also move into the new class IDE refactoring
- 32.
- 33. 33 Introduce Parameter Object Selecta list of arguments and press: right-click->refactor->extract -> Parameter object… IDE refactoring
- 34. 34 Extract Class Motivation: • Classesshould be small with a single responsibility • Often you need to extract a class to reuse it in different places. IDE refactoring
- 35.
- 36. 36 Extract SuperClass Motivation: • Youneed a new class which is very similar to an already exists class except for small differences. • Or, you already have two classes which are very similar except for some small differences. IDE refactoring
- 37. 37 Extract SuperClass –example: IDE refactoring
- 38.
- 39. 39 Move method Motivation: Move methodswhen classes are collaborating too much and are too highly coupled. IDE refactoring
- 40. 40 Move method –example: IDE refactoring
- 41. 41 Move method Select amethod and press right-click->refactor->extract ->Move… IDE refactoring
- 42. 42 Pull members up Motivation: Afield/method is duplicated on 2 or more subclasses. This field/method should be located in the super class. IDE refactoring
- 43. 43 Pull members up Selecta method and press right-click->refactor->extract ->Pull members up… IDE refactoring
- 44. 44 Push members down Motivation: Afield/method on a superclass is relevant only for some of its subclasses. IDE refactoring
- 45. 45 Push members down Selecta method and press right-click->refactor->extract ->Push members down… IDE refactoring
- 46. 46 Exercise – Videostore
- 47. 47 Exercise – Videostore
- 48.
- 49. 49 Legacy code -intuition BLACK BOX SCARY Tangled UGLY FRAGILE BAD DON’T TOUCH!! What do you think of when you hear the term “Legacy code”?
- 50. 50 The definition oflegacy code A direct definition: A legacy code is a code that we’ve gotten from someone else Michael Feathers’ definition: “To me, legacy code is simply code without tests” Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
- 51.
- 52. 52 The essence ofAgile programming are short feedback loops. The faster you get feedbacks, the smaller your deviations are. Short feedback loops
- 53. 53 The best toolto achieve short feedback loops is unit tests because they run very fast! Unit tests – feedback loop
- 54. 54 Refactoring is aboutchanging the program in small steps supported by tests. If you make a mistake, it is easy to find the bug. Yet again, what is refactoring?
- 55. 55 What is thereal purpose of automated tests? • Automated tests are a very important tool, but not for bug finding, not directly, at least. • In general, the purpose of automated tests, is to preserve behavior that is already there. The purpose of automated tests
- 56. 56 A good unittest is: • Fast (0.1 second to run is slow!) • Independent (why?) • Repeatable (why?) • Self validating (why?) • Easy to write and maintain Unit tests
- 57. 57 A test isnot a unit test if: • It talks to a database. • It communicates across a network. • It touches the file system • You have to do special things to your environment (such as editing configuration files) to run it. Unit tests
- 58.
- 59.
- 60. 60 “Before you startrefactoring, check that you have a solid suite of tests. These tests must be self-checking.” (Martin Fowler) Tests & Refactoring
- 61. 61 Legacy code dilemma Toput tests in place, we often have to change code. But, when we change code, we should have tests in place. During this process, you’ll have to make compromises. There might be a scar left in your code after your work, but everything beneath it can get better If later you can cover code around the point where you broke the dependencies, you can heal that scar, too.
- 62. 62 The recipe for legacycode change.
- 63. 63 • Identify changepoints • Find tests points • Make the code testable (break dependencies) • Write tests • Make changes and refactor The recipe for legacy code change
- 64. 64 To make thecode clearer, do safe changes: • Delete unused code • Use the power of the IDE to make safe changes! • Remove duplications • Make heavier refactorings, but… revert changes Identify change points
- 65. 65 • Identify changepoints • Find tests points • Make the code testable (break dependencies) • Write tests • Make changes and refactor The recipe for legacy code change
- 66. 66 Interception points An interceptionpoint is a place where a test can be written to sense behavioral changes. Class A public method that returns some value Save some value to DB / File / etc. Save some value to a global variable Invoke methods of other classes
- 67.
- 68.
- 69.
- 70.
- 71.
- 72. 72 Exercise – Triviagame Pop Science Sport … … … … … … … … … • You roll a dice (from 1 to 6) • You move on the board accordingly and answer the relevant question. • For a correct answer you get a coin • For a wrong answer you get into penalty. • As long as you are in penalty, your correct answers are ignored. • You get out of penalty for every odd roll. • The winner is the first player who has 6 coins.
- 73. 73 Exercise – Triviagame places printCategroy Print question printPlayerLocation currentCategory askQuestion
- 74. 74 • Identify changepoints • Find tests points • Make the code testable (break dependencies) • Write tests • Make changes and refactor The recipe for legacy code change
- 75. 75 Legacy code isalmost never testable. Make the code testable
- 76. 76 In legacy, puttinga class under test is hard: • Objects of the class can't be created easily. • The constructor we need to use has bad side effects. • Significant work happens in the constructor, and we need to sense it. • High coupling between components Make the code testable
- 77. 77 Make the codetestable
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84. 84 Irritating global dependency Extract& Override
- 85. 85 Irritating global dependency Extract& Override
- 86.
- 87.
- 88.
- 89. 89 Train wreck Using thelaw of Demeter )tell don’t ask!)
- 90. 90 Train wreck Using Extract& Override
- 91.
- 92.
- 93.
- 94.
- 95. 95 • Identify changepoints • Find tests points • Make the code testable (break dependencies) • Write tests • Make changes and refactor The recipe for legacy code change
- 96. 96 So, how dowe write the right tests? Write tests
- 97. 97 A characterization testis a test that characterizes the actual behavior of a piece of code. • Often, in legacy systems, what the system does is more important than what it is supposed to do. • If we make finding and fixing all of the bugs our goal, we'll never finish. Characterization tests
- 98. 98 Algorithm for writingcharacterization test: 1. Write a test to some code and choose some state. 2. Write some arbitrary assertion that you know will fail. 3. Let the failure tell you what the behavior is. 4. Change the test so that it expects the behavior that the code produces. 5. Repeat. Characterization tests
- 99. 99 Characterization tests Alter thetest to pass: Example:
- 100. 100 Characterization tests Alter thetest to pass: Another example:
- 101. 101 Characterization tests We coulddedicate a good portion of our lives to writing case after case for this class. When do we stop? We aren't writing black-box tests here. We are allowed to look at the code we are characterizing.
- 102. 102 • Identify changepoints • Find tests points • Make the code testable (break dependencies) • Write tests • Make changes and refactor The recipe for legacy code change
- 103.
- 104.
- 105. 105 There are 2main strategies to do large changes: • Big Bang • Divide and Conquer Refactoring strategies
- 106. 106 This strategy canbe implemented in two ways: o Do the large change on a separate branch and do a large merge at the end. o Stop the development of the old product and start the development of a new one Big Bang
- 107. 107 A continuous refactoringof one unit into smaller pieces until the desired goal is achieved. Divide & Conquer
- 108. 108 The Mikado Methodis considered as a Divide & Conquer strategy. The Mikado Method is a structured way to make significant changes to complex code. The Mikado Method
- 109. 109 Do complicated, longbig changes on the main brunch or stream, without ever having a broken code base. Mikado Method – the goal
- 110.
- 111. 111 The method itselfis straightforward and simple: After you’ve decided on a goal, you start to build a model of required changes and dependencies by doing quick experiments. Mikado
- 112.
- 113. 113 • Set agoal • Experiment • Visualize • Undo Mikado – basic concepts
- 114. 114 Mikado – thealgorithm
- 115. 115 Mikado – demonstration Wewant to get from this: To this:
- 116.
- 117.
- 118.
- 119.
- 120.
- 121.
- 122.
- 123. 123 Exercise – Loansapplication
- 124. 124 Exercise – Loansapplication Three actions: • Apply: http://localhost:8080/?action=apply&amount=10000&contact=donald@ducks .burg • Fetch: http://localhost:8080/?action=fetch&ticketId=2 • Approve: http://localhost:8080/?action=approve&ticketId=2
- 125.
- 126. 126 Conclusions • Refactor andclean your code constantly, or else, it will become harder and harder for it to evolve.
- 127. 127 Conclusions • Refactoring isabout changing the program in small steps supported by (mostly unit) tests. If you make a mistake, it is easy to find the bug.
- 128. 128 Conclusions • Legacy codeis simply a code without tests – without them, you are afraid to clean it. • If you are dealing with a legacy code, put some constant effort to cover it with a comprehensive suite of unit tests.
- 129. 129 Conclusions • If youare about to make a change and you know beforehand that this change is going to be a medium/large scale change – use the Mikado Method. • If you started a change and this change spirals out of control – revert everything and start to use the Mikado Method.
- 130. 130 Conclusions • There areno free meals, to improve your code, you need to put an effort! An effort in writing tests, an effort in refactoring.
- 131.
- 132. 132 Automated testing Integration testsare a scam Pairwise testing Why most unit testing is waste Technical debts Managing technical debts (1) Technical debts with sonar Managing techincal debt (2) Books Working effectively with legacy code [Michael C. Feathers] The pragmatic programmer [Andrew Hunt, David Thomas] Refactoring: improving the design of existing code. [Martin Fowler] Clean Code [Robert C. Martin] Further reading
- 133.
- 134.
Editor's Notes
- #21 This of course will automatically rename all the references.
- #25 Here we can see quite nested invocation of methods which hurts the code readability.
- #26 Here we can see quite nested invocation of methods which hurts the code readability.
- #56 That’s a very important issue – when people think about the benefits of auto testing and there ROI, they think about bugs finding and that’s a very poor goal.
- #65 - Remove player1Name and player2Name Remove remarked code. Remove unused method “isTied()” Rename m_score1 to scoreOfPlayer1 (the same for 2) Extract the first switch case to a method called “getTiedScore” Extract the if expressions such as scoreOfPlayer1>=4 || scoreOfPlayer2>=4 to methods. Instead of scoreOfPlayer1 += 1 use scoreOfPlayer1 += POINT Show introduce variable on the code extractState(new StateLoader().loadFromDB()); Show heavier refactoring and then revert by refactoring the last switch statement.
- #68 We need this change: generateIndex should not generate a new index every time we call it, but rather update or replace the existing index if any. Let’s find which outputs of this class our change is going to effect in order to test the right things.
- #69 Is that it? Index.text is also influenced.
- #71 Important to say: this does not mean that you will have to do this sketches for every change you are about to do, but it’s a good tool for complicated cases, and often it can be done informally in you head.
- #72 Do effect sketches for the trivia game.
- #73 SHOW THE CODE!!! INCLUDING THE RUNNER CLASS!!!
- #78 The best way to understand if your class can go under test is to just do it.
- #81 Clients of CreditValidator don’t need to change – they are not effected.
- #82 Tell them what the code does and ask them what is the problem to test this kind of code.
- #83 Again, clients of StockSeller don’t need to change – they are not effected.
- #86 But some times it’s not worth it, the call to the singleton is scattered all over the code.
- #87 Must the constructor of the singleton stay private? Often people create singletons because they want to have a global variable. They feel that it would be too painful to pass the variable around to the places where it is needed. In that case, we can relax the singleton property and make the constructor protected and keep the constructor of the derived class as private.
- #92 Ask when this will be triggered? First, try to see if it can work this way, maybe it does not go to the DB…? If it’s not working on first shot, try to see if you can make it pass easily. If none of these works – refactor like in the next slide.
- #94 Ask when this will be triggered? First, try to see if it can work this way, maybe it does not go to the DB…? If it’s not working on first shot, try to see if you can make it pass easily. If none of these works – refactor like in the next slide.
- #104 Do effect sketches for the trivia game.
- #124 Do effect sketches for the trivia game.
- #125 Do effect sketches for the trivia game.