CSC/ECE 517 Spring 2014/ch1a 1w1e rm

From Expertiza_Wiki
Jump to navigation Jump to search

This page discusses refactoring techniques and metrics. It also includes tips on refactoring in Ruby and list of tools for automated refactoring.

Background

The idea behind code refactoring is to take a code base and improve it's readability, extensibility, and reusability. The practice is focused on having a better quality and more standardized code base, and not on fixing bugs or changing functionality.

Refactoring has its difficulties, whether or not it is done using an IDE or whether it is done by hand. There are lots of pitfalls and errors that can be made during refactoring, so it is pertinent to determine how important a refactor is to the code. Code metrics are one method used to determine how badly a file needs refactoring.

Refactoring Techniques

Before a coder performs a refactor, they must, either formally or informally, identify their ‘code smells’. A code smell refers to a negative quality of a code base that either implements bad programming practices or slows down code development or runtime. These aren't typically bugs, but can increase the chance of bugs later on if not fixed. Based on the type of code smell, a different refactoring technique is used to fix it.

Duplicate Code

Duplicate code can be a tricky concept when refactoring. Large sections of duplicated code can be easy to find and fixed by pulling it out and creating a single centralized method to call, however it is usually not that easy. Sometimes it may only be one or two lines of code that are duplicated which calls for an assessment of whether or not it is in the best interest to create a new method for a couple lines of code. Other times, code is not duplicate, rather it is similar enough that a generic method could be created to serve various purposes. Some specific techniques to deal with this are:

  • Extract Method / Pull-up Method
    • If common code is used in multiple places, simply pull it out and make a method that can be called from all of the necessary places. Variables can be passed in if slight variations are needed between calls.
    • If the code is used in various subclasses, put the common code in a method in the superclass, so that it can be seen and called by it’s children.
    • Extract Method Example

Large Method/Class

If a project is not planned out well enough in advance, it is easy for methods and classes to become populated with excess functionality. While functionality of a block of code may be necessary for the project, the code block might not really pertain to the method or class it is included in.

  • Extract Method
    • This can be used when duplicate code occurs, as discussed above. But it can also be used when a method performs multiple functions that have the ability to be split up into various functions that serve a single purpose.
  • Extract Class/Subclass/Superclass
    • If there are class variables or methods that don’t directly pertain to a class, then it may be necessary to create a new class for those pieces.Example
    • If there are pieces of a class that are only for a specific subset of instances, then a subclass can be constructed to contain these.Example
    • If there are pieces that multiple classes use, then a superclass can be constructed to handle these generic functions, leaving the subclasses to deal with the remaining differences Example

Improving Readability and Clarity

Many times, refactoring can be used to do simple, yet necessary changes like renaming variables, methods, or classes. As features get added to a project, classes tend to get charged with more uses than originally planned, so sometimes, the original naming scheme no longer applies and a new one needs to be instilled.

Moving methods and parameters around to where they have the best accessibility also has its uses. Classes also tend to be promoted or demoted to super and sub classes after their ultimate functional purpose is determined.

More Techniques

There is an extensive list of coding smells that can be improved through refactoring.

A description of smells with their techniques exists here.

A list of techniques with examples in Ruby are listed here.

Metrics

It can be hard to decide whether or not to refactor, especially when it’s for something that appears to be working fine with just a surface level smell. Program analysis tools are used to derive various types of code metrics, which allow coders to identify problem areas and future pitfalls of their code base. These tools look at the code in several different ways, including the number of times a source file has been edited to help determine if it is a possible target of [feature envy], duplicate code structure to identify replicated lines, and block depths to suggest possible complexity issues.

Open Source Ruby Metric Tools

There are a variety of open source code metric tools that can be employed specifically for Ruby programs. The Ruby Toolbox contains the most popular of these tools along with ratings.

Simple Cov is at the top of this list. It was developed specifically to be of use to anyone using any framework. It integrates itself with the project’s own test cases to check the code coverage of them in addition to cucumber features.

Code Climate

Code Climate is a hosted code metrics tool that analyzes projects in a multitdue of ways. It produces three main metric ratings with grades from A-F that comprise of the methods and classes contained in each file and project.

Complexity Metric

This is based off of the Assignment, Branches, and Conditions (ABC) metric, where the number of assignments, branches, and conditions are counted and analyzed. However, because Code Climate is constructed for Ruby programs, it also takes into account certain types of Ruby constructs that may increase the metric score, but are actually beneficial to the project.

Duplication Metric

This looks at the syntax trees of the code in order to identify identical and similar code structures. Because the syntax trees are being analyzed, code formatting and different method and class names do not affect the score. <ref>https://codeclimate.com/docs#quality-metrics</ref>

Churn Method

This integrates with the Git repository to look at the change history of the project’s files. Files with excessively high change histories have a tendency to have a high complexity rating as well, as they can be the result of feature envy, where extra functions are added into a file instead of being added to a new file with it’s own functionality.

Getting Started with Refactoring in Ruby

First step: Writing tests

The first step in refactoring is writing solid set of tests for the section of code under consideration, in order to avoid introducing bugs. In Ruby, this can be done using Test::Unit or Rspec. Next step is to make small changes, test, make small changes, test again and so on<ref name='Refactoring Ruby Edition'>http://www.amazon.com/Refactoring-Edition-Addison-Wesley-Professional-Series/dp/0321984137</ref>. This ensures that we can revert back to the working version of code if any small refactoring causes the application to stop working.

When to refactor

It is always confusing when to start refactoring. If either one of the following conditions is true, it is a good time to start refactoring code<ref name='Refactoring Ruby Edition'/>:

  • The Rule of Three - If any code segment gives trouble more than two times, it is time to refactor it
  • Adding new function - It might be helpful to refactor when adding new functionality as it would give better understanding of code. Sometimes, revisiting old design might help to accommodate new features better
  • Fixing a bug - It is useful to refactor code which had a bug; this might save bug reports from the same piece of code in future
  • During code review - Refactoring is useful during code reviews as it can be applied immediately making code reviews more fruitful
  • Understanding other's code - If a new member joins the team and is asked to refactor existing code, it helps them to get a better understanding of the code base. It might take extra time to get them started, but trying to refactor will help them contribute to the project better in the long run.

A CodeClimate blog suggests some other conditions to decide when to refactor code.

Refactoring fat models

As more features get added to the application, the models tend to become bulkier. Such fat models cause maintenance issues. Refer to CodeClimate blog for 7 patterns to refactor such fat models.

Refactoring views

In this talk, Brian Hughes explains use of patterns to refactor views with bad code smells like use of conditionals or formatting data.

Automated Code Refactoring

RubyMine

RFactor

  • RFactor is a Ruby gem, which aims to provide common and simple refactorings for Ruby code for text editors like TextMate
  • The first release has only Extract method implemented while other refactorings are coming soon
  • It is available on GitHub

Other IDEs

  • Some other IDEs with built-in refactoring include Aptana Studio, Aptana RadRails and NetBeans 7 (which requires Ruby and Rails plugin)
  • A StackOverflow post compares these tools ranking them as RubyMine being the best, followed by NetBeans, RadRails 2 and Aptana Studio 3

Further Reading

References

<references/>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2014/ch1a_1w1e_rm&oldid=83210"