Refactoring. Software Engineering, DVGC18 Faculty of Economic Sciences, Communication and IT Eivind Nordby

Transcription

1 Refactoring Faculty of Economic Sciences, Communication and IT

2 Why Refactor Refactoring is one factor in keeping your system in shape Without continuous refactoring, the system will rot It takes on technical dept Quality Ideal utopia With continuous refactoring Technical dept Time No refactoring Rotting system

3 What is Technical Dept? Not-quite-right code, Like unwashed dishes not washed up after dinner Nobody can describe exactly what it is But you recognize it when you see it Ask In which part of the system would you rather not work? Shipping first time code is like going into debt You hurry to reach your deadline Cutting quality Skipping refactoring I ll do it later, there is no time right now

4 Time Pressure and Velocity Consider a project with a tough deadline and high development speed Scope No refactoring Break even Next target Project target With continuous refactoring Sustainable pace After successful first delivery Project manager is promoted and moves on Developer is promoted Then, quickly move on to another job! Time

5 Technical Dept and Velocity Why is technical dept a problem? It slows down development The danger occurs when the debt is not immediately repaid Every minute spent on not-quite-right code counts as interest on that debt A little debt speeds development As long as it is paid back promptly with a rewrite If the dept is not payd back, code gets worse and worse Velocity drops because of bad code that is difficult to change You fall behind more and more and need to rush to meet your deadline You produce more and more crap in less and less time

6 Refactoring Examples of technical dept / smells Duplications Less than best naming Long methods / large classes taking care of several tasks Long parameter lists, symptom of mixing tasks Message chains, like t.get().get().get().get() Comments (because code would be impossible to understand without them) Mixing what (the objectives) with how (the algorithmic details) Refactoring is a means to repay the technical dept

7 The Essence of Refactoring Always refactor in small steps on working (green) code Because each change is small, any errors are very easy to find You don't spend long debugging, even if you are careless One benefit from TDD is to support refactoring By continuously running all the old specification examples ( tests ) Like a security net

8 A problem?

9 So, what is Refactoring? Refactoring is a disciplined technique for restructuring an existing body of code ALTERING ITS INTERNAL STRUCTURE WITHOUT CHANGING ITS EXTERNAL BEHAVIOR Its heart is a series of small behavior preserving transformations Each transformation (called a 'refactoring') does little A sequence of transformations can produce a significant restructuring Since each refactoring is small, it's less likely to go wrong The system is also kept fully working after each small refactoring reducing the chances that a system can get seriously broken during the restructuring. Source: Fowler, Martin, Refactoring Home Page, with permission

10 Refactoring Kata The sample program is a program to print out a statement of a customer s charges at a video store. There are several classes that represent various video elements. Here s a class diagram to show them. DomainObject #name: string Movie Tape Rental Customer +pricecode: int daysrented: int -* +statement() Source: Fowler, Martin, Refactoring, a first example,

11 1 Refactoring: Inappropriate intimacy Subclass constructors set instance variable _name in base class DomainObject Change assignment to base class variable in constructor -> Delegate to base constructor public Customer(string name) {_name = name} -> public Customer(string name) : base(name) { } Make the base class variable private

12 Quality Assessment Customer holds all the behavior for producing a statement in its Statement() method. The long Statement method does far too much, and is certainly not objectoriented Loops rentals Selects right kind of rental Computes and accumulated rental costs Computes frequent renter points based on rentals Formats and fills in statement report Many of these things should really be done by the other classes

13 New user requirement: Similar statement in HTML Neither Statement() nor any of its parts is reusable Requires a complete rewrite Copying large parts of the Statement() method to HtmlStatement() and modify selected parts Not too complicated But what happens when details change? Charging rules Frequent renter points New movie codes etc When changes are likely to come, copy and paste is a threat to quality

14 Is if it ain t broke, don t fix it still valid? Statement() is making life painful for HtmlStatement() Enters refactoring When you find you have to add a feature to a program, and the program s code is not structured in a convenient way to add the feature; then 1. first refactor the program to make it easy to add the feature, 2. then add the feature.

15 2 Extracting the Amount Calculation The Statement() method is too long and does too much Extracting a method is taking the chunk of code and making a method out of it. An obvious piece here is the switch statement Mark the switch and choose Refactor -> Extract Method It wants each and thisamount as parameters each is initialized outside and is not modified inside thisamount is initialized outside and is modified inside

16 Finding the boundaries of the method block The initialization to zero is at the top of the each loop

17 Adjusting the block boundaries Include the initialization of the temporary variable in the method extraction First move it closer to the block to extract Use the comment as the method name (will allow for removal of comment later) static confirms that the method is idependent of the Customer object

18 The result The comment is now redundant May be removed static has been removed in the new, private method declaration Verify that all tests still pass VS refactoring helps to avoid silly mistakes

19 3 Improving Variable Names AmountOf is now an independent calculation in its own right Makes it easier to consider variable names in isolation Should be reflected in the parameter name Make it more generic Mark it and press F2 (or right click and choose Refactor -> Rename) Type arental as the new name Respects the Principle of Least Astonishment Also rename thisamount to result

20 Result of renaming variables Good code should communicate what it is doing clearly, and variable names are key to clear code. Never be afraid to change the names to things to improve clarity Remember any fool can write code that a computer can understand, good programmers write code that humans can understand.

21 4 Moving the Amount calculation We saw that AmountOf does not use information from Customer But it does use information from Rental Rental is the Information Expert The method belongs in the Rental class, not the Customer class Move it there

22 Moving a method Compile after each step Copy the code over to Rental, adjust it to fit in its new home and compile In this case, remove the parameter arental Make the method public Locate the calls to the old method and modify the call (Find All References) AmountOf(someRental) -> somerental.amountof() Only one place in this case, since we just created the method Run the tests after each substitution Delete the old method Rename the new method to something more appropriate For instance AmountOf() -> Charge()

23 5 Replacing temp thisamount with a query The variable thisamount is assigned a value that never changes From each.charge() It may be Replaced by a call to each.charge() at each occurrence and dismissed Temps are disturbing

24 6 Extracting the Frequent Renter Points Calculation The calculation of frequentrenterpoints is done incrementally Each increment is calculated independently of the previous ones

25 The refactoring Extract Method doesn t do the trick Extract Method notices that the new value is based on the old one We extract the method in smaller steps 1. Introduce a temporary variable to compute the new value, Run the tests 2. Extract method using that temp variable, Run the tests 3. Replace the new temp with the call to the new method, Run the tests 4. Rename method and temps, Run the tests 5. Move and rename the new method to the Rental class, Run the tests

26 Extract Method in smaller steps 1. Introduce a temporary variable to compute the new value 2. Extract only the parts that do not involve frequentrenterpoints

27 Extract Method in smaller steps 3. Replace the temp by the call to the new method

28 Extract Method in smaller steps 4. Clean up method and temp names

29 Extract Method in smaller steps 5. Move and rename the new method from the Custom class to the Rental class and remove the now redundant comment

30 7 Removing temps Temporary variables are useful within their own routine Encourages long, complex routines Prevents functionality from being used in other contexts We have two temporaries, totalamount and frequentrenterpoints

31 Working towards more than one goal at a time Both variables are accumulated in the loop The loop breaks the Single Responsibility Principle Doing at least three tasks at the same time Computing the total charge Computing the frequent renter points Formating the statement Computing the charge and frequent renter points will both be needed in both Statement and HtmlStatement But HtmlStatement will need a different formating The totals will be more accessible if broken out as separate queries Encouraging a cleaner design without long, complex methods

32 Replace totalamount with a Charge() method Copy the whole of Statement() Rename to Charge() Change return type to double and return totalamount Remove anything not related to calculating the totalamount Rename totalamount to result, refactor to lambda expression requires using System.Linq; Replace totalamount in the footer line of Statement() by Charge()

33 What was achieved by Replace Temp with Queries? The total summed up in totalamount is not used any more The variable can be removed and the tests run The total charge is made accessible as a public operation to whom it might concern The net number of lines of code has slightly increased Due to the overhead of writing the extra method and the loop overhead Lambda expressions compensate for that Performance might suffer from the collection of rentals being looped through one extra time (and yet another for the frequent renter points to come) Valid concerns if the loop takes time Most do not, and if they do, isolating the operations empower optimization

34 Replace frequentrenterpoints with a query Following the same procedure Calling the new procedure int FrequentRenterPoints()

35 8 Adding HtmlStatement HtmlStatement may now easily be written And a corresponding test added The pattern is still copied from Statement, may be refactored further

36 9 Moving Rental Calculations to Movie The switch statement in Rental.Charge is disturbing Switches based on an attribute of another object. Bad idea Move the Charge to Movie Copy Charge from Rental to Movie Remove Tape.Movie. from the switch statement Add parameter int DaysRented Rename DaysRented to daysrented Remove Movie. from the case clauses Compile Replace the body of Rental.Charge with return _tape.movie.charge(_daysrented); Run all the tests Move FrequentRenterPoints to Movie in a similar way

37 10 Hiding Movie price codes Introduce creation methods To avoid pattern new Movie("Home Alone", Movies.REGULAR); And similar for NewRegular and NewChildrens Movies can also change their classification amovie.setpricecode(movie.regular) does not work any more Make Be methods in Movie as an explicit interface

38 11 Inheritance A class hierarchy for the three types of movies might be like this Using polymorphism Movie +Charge() ChildrensMovie +Charge() REgularMovie +Charge() NewReleaseMovie +Charge() Only, this does not allow for a movie to change its classification during its lifetime An object cannot change its class during its lifetime

39 State pattern A solution using the state pattern All the new leave classes are singeltons Movie +Charge() -1 Price +Charge() return pricecode.charge(); ChildrensPrice RegularPrice NewReleasePrice +Charge() +Charge() +Charge() Move date and methods in small pieces to avoid errors

40 Create the classes Let the Price base class own and manage the singleton instances The singleton classes are subclasses of Price

41 Move data over to the new classes Move the price code to the new classes Or modify the methods that use the codes so they work the same as before First, self-encapsulate the type code Let all access, even from within the Movie class use setter and getter properties Replace By And make a new constructor Movie(string name) : base(name) { }

42 Change getting and setting methods in Movie First run all the tests Set a new _price attribute in BeRegular etc. Leaving the old code for the time being, so that all the tests pass Supply Price and subclasses with a PriceCode getter property In Price: In ChildrensPrice: Movie.CHILDRENS e.al. need to be made public again for a short while

43 Clean up Movie._priceCode Modify Movie.PriceCode to return _price.pricecode Check the remaining references for _pricecode in Movie Constructor Movie(string name, int pricecode) is not used any more Delete it The remaining references only set _pricecode It is not read any more Delete all occurrences of it Run all the tests

44 Move methods from Movie to Price Move Charge(), Replacing it by return _price.charge(daysrented); in Movie Run the tests Successively replace the case statement with inheritance One leg at a time Make Price.Charge virtual (=overridable) Make an override in the subclasses, one at a time Copy the logic from the corresponding case leg

45 Reminder: The target structure DomainObject #name: string Price Movie Tape Rental Customer +Charge() +pricecode: int +Charge() +daysrented: int * +Statement() NewReleasePrice +Charge() RegularPrice +Charge() ChildrensPrice +Charge()

46 The Charge methods RegularPrice: NewReleasePrice: ChildrensPrice: Make Price.Charge() abstract

47 Move FrequentRenterPoints Move FrequentRenterPoint() to Price Forward call from Movie to _price.frequentrenterpoints(daysrented) Make the new method in Pricevirtual Change to cover the default case inprice Override in NewReleasePrice only

48 Remove the price codes Verify that Price.PriceCode is only called by Movie.PriceCode Which in turn is never called Verify that the price code constants in Movie are only used by PriceCode in the corresponding Price subclass Remove all price code constants and PriceCode methods Inserting the state pattern was quite an effort The benefit is that it will be far easier to add new price codes or modify price structures

49 When to refactor? Refactor when you add function Refactor first Add new functionality then (in a green mode) Refactor when you fix a bug Obviously the code wasn't good enough to see the bug in the first place Refactor when doing code reviews It might be clear to you, but not to others Pair programming is code review

50 When are we done refactoring? Is like asking When are we done doing the dishes? Or When are we done weeding the garden There is always more weed coming