Code SmellRe-define refactoring at NAL (& code review)Lan@NAL 201612

Once upon a timeWe have “Code Review” on own SDP (Software Development Process), we always said “do refactoring", but ...

Once upon a timeWe did not know own code have bad smells, until ...

NOT BAD

Code Smell

Martin Fowlerhttps://martinfowler.com/bliki/CodeSmell.html

"A code smell is a surface indication that usually corresponds to deeper problem in the system."

In computer programming, code smell is any symptom in the source code of program that possibly indicates a deeper problem. Code smells are usually not bugs, they are not technically incorrect and do not currently prevent the program from functioning.

Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

"A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem."

Kent Beckhttp://wiki.c2.com/?CodeSmell

Code Smells = Warning SignsCode Smell ≠ A problem

Code Smell

“Bad code smells are symptons of poor design or implementation choices” [Martin Fowler]

● Pragmatic: code smells should be considered on a case by case basis● Purist: all code smells should be avoided, no exceptions

Code Smell (taxonomy)

Smells Between Classes

Smells Within Classes

Object-orientation Abusers

Bloaters

Dispensables

Change Preventers

Couplers

Others

Encapsulation

Abstraction

Modularity

Hierarchy

Code SmellBad Smells:

● Bloaters

● Object-orientation Abusers

● Change Preventers

● Dispensables

● Couplers

Code SmellBloaters

Bloater smells represents something that has grown so large that it cannot be effectively handled.

Long Method: A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions.

Large Class: A class contains many fields/methods/lines of code.

Long Parameter List: More than three or four parameters for a method.

Data Clumps: Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database).

Primitive Obsession:

Use of primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.)

Use of constants for coding information (such as a constant USER_ADMIN_ROLE = 1 for referring to users with administrator rights.)

Use of string constants as field names for use in data arrays.

Code SmellObject-orientation Abusers

All these smells are incomplete or incorrect application of object-oriented programming principles.

Switch Statements: have a complex switch operator or sequence of if statements.

Temporary Field: Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they are empty.

Refused Bequest: If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions.

Alternative Classes with Different Interfaces: Two classes perform identical functions but have different method names.

Code SmellChange Preventers

These smells mean that if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more complicated and expensive as a result.

Divergent Change: You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products.

Shotgun Surgery: Making any modifications requires that you make many small changes to many different classes.

Parallel Inheritance Hierarchies: Whenever you create a subclass for a class, you find yourself needing to create a subclass for another class.

Code SmellDispensables

A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand.

Comments: A method is filled with explanatory comments.

Duplicate Code: Two code fragments look almost identical.

Lazy Class: Understanding and maintaining classes always costs time and money. So if a class doesn't do enough to earn your attention, it should be deleted.

Data Class: A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters). These are simply containers for data used by other classes. These classes do not contain any additional functionality and cannot independently operate on the data that they own.

Dead Code: A variable, parameter, field, method or class is no longer used (usually because it is obsolete).

Speculative Generality: There is an unused class, method, field or parameter.

Code SmellCouplers

All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation.

Feature Envy: A method accesses the data of another object more than its own data.

Inappropriate Intimacy: One class uses the internal fields and methods of another class.

Message Chains: In code you see a series of calls resembling $a->b()->c()->d()

Middle Man: If a class performs only one action, delegating work to another class, why does it exist at all?

Code SmellOthers

Incomplete Library Class: Sooner or later, libraries stop meeting user needs. The only solution to the problem – changing the library – is often impossible since the library is read-only.

SO WHAT?!

RefactoringIn real world, WORKING WITH CODE ...

20% Write new code

80% Modify existing code

Refactoring●Unreadable Code …

●Duplicated Code …

●Complex Code …

…

Bad Smell Code is

HARD to MODIFY

RefactoringRefactoring is ...

●Easier to Understand

●Cheaper to Modify

“Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

Refactoring

Code Smells

Software Quality

Code Quality

READ

High Quality Code = easy to UNDERSTAND

CHANGE

In the Long Run, High Quality Code Costs less

Refactoring process ~ create Quality Code

Refactoring

Request Review

Review Comment

Refactoring

Repeat

Commit Code

Code Review

● Choose worst bad smell● Select a refactoring● Apply the refactoring● Run all tests

Refactoring

Refactoring“With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.”

So…

HOW to do refactoring in a controlled and efficient manner?!

More reading/explore● Refactoring: Improving the Design of Existing

Code (by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

● Refactoring Workbook (By William C. Wake)

● http://www.slideshare.net/mariosangiorgio/clean-code-and-code-smells

● http://mikamantyla.eu/BadCodeSmellsTaxonomy.html