Refactoring

Code refactoring


As Martin Fowler explained in his book ("Refactoring: Improving the Design of Existing Code"), refactoring is a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactoring has the following benefits:

  • It Improves the Design of Software
  • It Makes Software Easier to Understand
  • It Helps You to Find Bugs
  • It Helps You Program Faster

Need for Refactoring comes when code smells are found in the software. A code smell is any symptom in the source code of a program that possibly indicates a deeper problem.

Kent Beck and Martin Fowler have listed the followings code smells :

  • Duplicated code : Don't Repeat Yourself (DRY Principle)
  • Comments : No comments in the code.
  • Bad names : Names should express intentions.
  • Long method : Method should be small
  • Large class : Classes should be small
  • Long parameter list : Parameter list should be short
  • Divergent change : This smell refers to making unrelated changes in the same location : Single Responsability Principle is violated.
  • Shotgun surgery : Every time you make a change, you have to make a lot of little changes to a lot of different classes.
  • Feature envy : A method is more interested in a class other other than the one it actually is in.
  • Data clumps : You see a set of data items together in lots of places.
  • Primitive obsession : Objects blur or even break the line between primitive and larger classes. You observe recurrent concepts in your project that are not objects but primitives e.g. Currency, Id, dates. Business Logic around these concept spread through out the code.
  • Switch statements : Most times a switch statement should be replaced by polymorphism design
  • Parallel inheritance :When you make a subclass of one class, you also have to make a subclass of another.
  • Lazy class : A class that isn't doing enough to pay for itself should be eliminated.
  • Speculative generality : "Oh, I think we need the ability to do this kind of thing someday" and thus want things that aren't required (over-engineering).
  • Temporary field : Sometimes you see an object in which an instance variable is set only in certain circumstances. Trying to understand why a variable is there when it doesn't seem to be used can drive you nuts.
  • Message chains : Long line of getThis methods, or as a sequence of temps.
  • Middle man : Half the methods are delegating to another class. It is time to remove Middle Man and talk to the object that really knows what's going on.
  • Inappropriate intimacy : Overintimate classes need to be broken up as lovers were before wedding in ancient days.
  • Alternative classes with different interfaces : Use Renamed Method on any methods that do the same thing but have different signatures for what they do.
  • Data class : they are classes without behaviour, Procedural programmers tends to fall in this code smell.
  • Refused Bequest : Children classes doesn't want or need what they are given by Parents Classes. This means the hierarchy is wrong.

Resolving these code smells in your code leads to more efficient Object Oriented Programming design and so-called "clean code".

Books Blogs and Twitter Articles

Database refactoring


A database refactoring is a simple change to a database schema that improves its design while retaining both its behavioral and informational semantics. A database refactoring is conceptually more difficult than a code refactoring; code refactorings only need to maintain behavioral semantics while database refactorings also must maintain informational semantics.

The process of database refactoring is the act of applying database refactorings to evolve an existing database schema (database refactoring is a core practice of evolutionary database design). You refactor a database schema for one of two reasons: to develop the schema in an evolutionary manner in parallel with the evolutionary design of the rest of your system or to fix design problems with an existing legacy database schema.

Database refactoring does not change the way data is interpreted or used and does not fix bugs or add new functionality. Every single refactoring to a database leaves the system in a working state, thus not causing maintenance lags, provided the meaningful data exists in the production environment.

Books Articles

Team of Pyxis