Code Refactoring and Code Smells

• indicator or symptom of deeper design problem

• violation of fundamental design principles that decrease the overall quality of code

• not bugs or errors

• can certianly add to the chance of bugs and failures down the line

• difficult for software system to evolve and maintain

• Bloaters

• Object Orientation Abusers

• Change Preventers

• Dispersables

• Couplers

• metric based

• rules/heuristic based smell detection

• history based

• optimization based

code, methods, classes that have increased to such gargantuan proportions that they are hard to work with

incomplete or incorrect application of object oriented programming principles

if you need to change something in one place, you have to make many changes in other places -> development becomes more complicated and expensive as result

something pointless and unneeded whose absende would make the code cleaer, more efficient and easier to understand

contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation

• Designing solid test for the section to be refactored

• reviewing the code to identify bad smells of code

• introducing refactoring and running tests (One step at a time)

• Primitive fields are basic built-in building blocks of a language e.g. int, string or constant

• primitive obsession is when the code relies too much on primitives and when uses primitive types to represent an object in a domain

• one module is often changed in different ways for different reasons

• Classes have more than distinct responsibilities that it has more than one reason to change

• Violation of single responsibility design principle

You identify everything that changes for a particular cause and put them all together

• a single change is made to multiple classes simultaneously

• when changes are all over the place, they are hard to find, and it’s easy to miss important changes

• you put all the changes into a single class

• once and only once (OAOO)

• a function in one module spends more time communicating with function or data inside another module than it does within its own module

• move function to give it a dream home

• only some of the inheritances are need, i.e. hierarchy is wrong

• inheritance makes no sense and the subclass really does have nothing in common with the superclass

• good to have, can be simplified

• Best if code is self explanatory

  • if you need a comment to explain what a block of code does, simply the code

  • if the method is already extracted but you still need a comemnt to explain what it does, rename the method

  • if you need to state some rules about the required state of the system, use Assertion