Code Craftsmanship

Code Craftsmanship
Presented by: Nadeem Mohammad
Date: 10/7/2012
Make your problem open new doors for innovation and proudly say “processing by innovation”

ProKarma Recognized by Inc. Magazine as the
"Fastest-Growing IT Services Company in
July 12, 2012 © 2012 ProKarma | All Rights Reserved
America”
Confidential & Proprietary | www.prokarma.com

ABOUT ME (Nadeem Mohammad)

• Senior Technical Lead
• Web 3.0 COE lead
• ≃ 5 Years with Prokarma
• Two Sons
• Ibraheem
• Imran


Note
• I would be talking mostly about the following people
works.

Michael Feathers

Martin fowler

Dave Thomas

Grady booch
Ron Jefferies

Ward Cunningham


AGENDA

• Clean Code, Why?
• Common Terms
• Code Smells
• Design Smells (High Level)
• SOLID Principles (High Level)
• Architecture Smells (High Level)


The Rule

• Apply Common Sense
• Don’t get too dogmatic / religious
• Every decision is a tradeoff
• All other principles are just that
• Guidelines
• “best practices”
• Consider carefully if you should violate them -
but, know you can.


Clean Code, Why?


Clean Code, Why?

• There may not be same set of people
maintaining the code after the code is
written
• Write Code for who comes after you, not
for the computer


Clean Code, Why?

• Good Software == saved more money


Clean Code, Why?

• Design rot when not carefully maintained


Clean Code, Why?

• Say yes to Change


Common Terms

• Code Smells
• Refactoring
• Test Driven Development (TDD)


Common Terms : Code Smells

• A Code Smell is a hint that
something has gone wrong
some where in your code,
Use the smell to track down
the problem
• We would be discussing
more on this soon

What is that smell???
Did you write that Code?

Common Terms : Refactoring

• A process of changing a software system
in such a way that it does not alter the
external behavior of your code yet
improves its internal structure
• Refactoring brings patterns
into your code
• The goal of refactoring is
NOT to add new
functionality

Common Terms : TDD

• Does this happen to you
This change
should work
just fine.


Common Terms : TDD

• A new way of programming.
• A new way of thinking
• The Rule
• Only write code to satisfy a failing test
case.


Three laws of TDD

• Write no production code unless you have
a failing unit test
• Do not write more of a unit test than is
sufficient to fail (And not compiling is
failing)
• Do not write more production code than is
sufficient to make the failure pass.
• Rinse and repeat every minute


TDD Cycle


Clean Code Guidelines

• Identify Code Smells
• Many things make a design hard to
maintain
• Develop a nose for bad structures
• Long method
• Long class
• Feature Envy
• Duplicate code
• ……

Code Smells
Bloaters
• Long method
• Long class
• Primitive Obsession
• Long Parameter List
• Data Clumps

Couplers OO Abusers
• Feature Envy • Switch Statements
• Inappropriate Intimacy • Temp fields
• Message Chains • Refused Bequest
• Middle Man
Code Smells • Alt classes with diff.
Interfaces

Dispensables Change Preventers
• Lazy class • Divergent Change
• Data Class • Shotgun surgery
• Duplicate Code • Parallel inheritance hierarchies
• Dead Code
• Speculative Generality


Code Smells : Bloaters

• Bloater smells represent something
that has grown so large that it can not
be effectively handled
• This smells grow little bit at a time


Bloaters: Long method

The Problem The Solution

Readability : Longer code takes longer to read Break the method up into greater number of
and comprehend. methods or into other classes. Have one method
represent a single function and a class single
Reusability : A longer method may be to be able concept.
to split into methods and classes that can be
reused

Testability : a long method is likely to need more
testing.


Long method : Example
Imagine what could have happened if struts guys would have written all the code in the same method
instead of dividing into different methods


Bloaters: Long Class
• A Class has taken too much
responsibilities, and is modeling more
than one concept.

Complexity : if your class represents more than a Ensure that the class represents a single concept,
single concept, it will be harder to understand. and break it into several classes if it represents
more than a single concept.
Bloat : a greater number of fields and methods
will mean the class will take longer to understand. You may find that functionality or state could
belong to a different class, in which case
functionality or state could be moved to the other
class.


Bloaters: Long Class

Delegated the
responsibilities to
different classes


Bloaters: Long Parameter List
Methods that take too many parameters produce client code that is awkward and difficult to work with.


Understandability : lots of parameters will make Put the data into their own classes, and possibly
code harder to understand. break the method up into several methods. Ensure
that each method is performing a single function,
The method is doing too much - why does it need and each class modelling a single concept.
all of that information?
Limit the number of parameters you need in a
given method, or use an object to combine the
parameters.


Bloaters: Long Parameter List

6 parameters to just 1 parameter


Bloaters: Primitive Obsession

• Code is using primitive data types and method calls to generate desired
outcomes, and could be written in a more descriptive and sustainable way.
• Arises when we use primitive types (such strings or integers) to represent
what should be explicit types in our domain
• For example, using a string to store my name (“Nadeem Mohammad”)
would likely be a loss of an abstraction. This probably needs to be modeled
as a something more explicit such as a User or a Person, having a
FirstName and a LastName.
• Come up with Small classes like Money, Currency, PhoneNumber etc.

Reusability: Code written is not reusable. Don't use a gaggle of primitive data type variables
as a poor man's substitute for a class. If your data
It may be less clear to someone reading the code type is sufficiently complex, write a class to
what is going on. represent it.

Encapsulate data concepts in classes, and create
and call methods on objects of a class to attain
desired results.


Bloaters: Data Clumps

• If you always see the same data hanging around
together, maybe it belongs together. Consider rolling the
related data up into a larger class.
• An Example would be Address, FaxNumber Classes


Reusability: Code written Is not reusable. If the items are fields in a class, Encapsulate fields in a
separate new class.

If the values are together in method signatures, Introduce
Parameter Object to extract the new object.

Look at calls that pass around the items from the new
object to see if they can Preserve Whole Object instead.


Data Clumps: Example


Bloaters: Comments

• Fowler says “comments often are used as
a deodorant”
• Refactor code so that the comment
becomes extraneous, replace it with more
expressive code


Comments : Example

Turn comments into
code


Comments : Example


Dispensables

• They all represent something
unnecessary that should be removed
from the source code


Dispensables : Lazy Class

• A class isn't doing much—its parents,
children, or callers seem to be doing all
the associated work, and there isn't
enough behavior left in the class to justify
its continued existence


Lazy Class : Example

• Pull Up the calculatePostage() method.
• Make the Address class non abstract
• Remove the ShippingAddress Class.


Dispensables : Data Class

• A key goal of OO design is to minimize depedencies
between classes and components by packaging data
and behavior as close together as we can. In practice, a
good rule of thumb for class design is to put fields and
methods that use those fields in the same classes. Data
classes are classes which just have fields and no
behavior (besides simple getters and setters), and they
break this rule of thumb, creating serious dependency
issues in your code


Data Class : Example
This Class simply displays Student Summary

Move this method out to Student Class instead, And create a
method getAddressSummay() in Address Class


Dispensables : Duplicate Code

• Code that is the same, or performs the
same function are showing up in multiple
places within a program.


Bloat : more code will increase the size of Refactor the code, combine duplicate code into a method,
classes, making them more time or into separate classes.
consuming to read and understand.

Maintenance : changes to one of the
blocks of code will most likely cause other
blocks of code to also be changed. This
can also lead to greater defects if the
duplicate code isn't updated.


Duplicate Code: Example


Dispensables : Dead Code

• Code that is no longer used


Harder to comprehend the code base. Remove dead code. The following factors will help in doing so:

Wasted time - reading through, or even Domain knowledge : to ensure that the code is in fact dead.
changing dead code. Tools : is the code called from anywhere?
Testing coverage : can tests be run after deletion to ensure
functionality still works?
Version control will also help ensure that code can be restored
if accidentally deleted.


Dead Code: Example


Dispensables : Speculative Generality

• Creating today what we speculate will be
needed in the future (where there is no
current need for a particular feature /
design)

Wasted time creating code that isn't Design code to a specification. If a feature is needed in the
actually going to be used (it is dead). future, you can always refactor code if need be. Until that time,
remember YAGNI (You ain't gonna need it!).
Greater complexity : now there is
more code to sort through Just delete that darn code.


Code Smells : OO Abusers

• Solution does not fully exploit the
possibilities of Object Oriented Design
• For example a switch statement might
be considered acceptable or even good
design in procedural programming but
is something that should
be avoided OO
programming


OO Abusers: Switch Statements

• Switch statements are bad from an OO design
standpoint. Not only because they're basically big nested
IF statements, but because they have a tendency to
grow. A refactored switch statement would exploit
polymorphism, which is the OO way to make decisions
about how to do specific "stuff" at run time
• The situation where switch statements or type codes are
needed should be handled by creating subclasses
• Move each leg of the conditional to an overriding method
in a subclass. Make the original method abstract


Switch Statements : Example


OO Abusers: Temporary fields

• This smell occurs when a class has a field that is
only used some of the time. A class like this can
be hard to understand because you would
normally expect it to use all its instance variables
and it can be difficult to see what the temporary
variable is used for
• A variable is in the class scope, when it should
be in method scope
• A field is set only at certain times, and it is
null (or unused) at other times

Temporary fields : Example


OO Abusers: Refused Bequest

• If you inherit from a class, but never use
any of the inherited functionality, should
you really be using inheritance?
• Refused Bequest smells lack proper
inheritance design


Refused Bequest : Symptoms

• The subclass undefines an inherited method,
makes an inherited method private, or makes it
throw an exception when it is called ( Explicit
refusal)
• A class inherits from a parent, but an inherited
method just doesn't work when called on the
class (implicit refusal)
• An inheritance relationship between two classes
doesn’t make sense; the subclass just isn’t an
example of the parent


Refused Bequest : What can be done?

• If it's not confusing, you might decide to leave it
as is
• If there's no reason to share a class relationship,
then Replace Inheritance with Delegation.
• If the parent-child relationship does make sense
you can re arrange the class hierarchy


OO Abusers: Alternate Classes with different Interfaces

• Lacks a common interface for closely
related classes, so it can also be
considered a certain type of inheritance
misuse
• If you can find the similarities between the
two classes, you can often refactor the
classes to make them share a common
interface


Code Smells : Change Preventers

• Smells that hinder changing or further
developing the software


Change Preventers : Divergent Change

• Divergent change occurs when one class
is commonly changed in different ways for
different reasons There by Violating SRP
• You might refactor this class to extract
distinct responsibilities into new classes


Divergent Change : Example


Change Preventers : Shortgun surgery

• If a change in one class requires
cascading changes in several related
classes, consider refactoring so that the
changes are limited to a single class
• change several classes when changing
database from one vendor to another
• Try to fix this by pulling all the parts of the
code that have to change together into a
single cohesive class

Change Preventers : Parallel Inheritance Hierarchies

• A special case of shotgun surgery
• Every time you make a subclass of one
class, you also have to make a subclass of
another


Code Smells : Couplers

• Coupling among classes or subsystems is
a measure of how interconnected those
classes or subsystems are
• Tight coupling means that related classes
have to know internal details of each
other, changes ripple through the system,
and the system is potentially
harder to understand


Couplers : Feature Envy

• A method in ClassA seems way too
interested in the workings and data fields
of ClassB. The feature envy from ClassA
to ClassB is an indication of tight coupling
from ClassA to ClassB
• The usual fix is to try moving the
functionality of the interested method in
ClassA to ClassB, which is already closer
to most of the data involved in the task

Feature Envy : Example


Couplers : Inappropriate Intimacy

• When two classes exhibit an unhealthy
fascination with each other's bits, we call
the Inappropriate Intimacy. It's essentially
bi-directional feature envy
• Two classes are coupled tightly to each
other


Couplers : Message Chains

• Message Chains is a smell where class A needs data
from class D. To access this data, class A needs to
retrieve object C from object B (A and B have a direct
reference). When class A gets object C it then asks C to
get object D. When class A finally has a reference to
class D, A asks D for the data it needs.
• The problem here is that A becomes unnecessarily
coupled to classes B, C, and D, when it only needs some
piece of data from class D.
• The following example illustrates the message chain
smell: A.getB().getC().getD().getTheNeededData()


Couplers : Middle Man

• Represent a problem that might be
created when trying to avoid high coupling
with constant delegation.
• Middle Man is a class that is doing too
much simple delegation instead of really
contributing to the application.


Design Smell

Immobility

Opacity Rigidity

Design
Needless
repetition Smell Fragility

Needless
Viscosity
complexity


SOLID STUFF

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)


Cohesion and Coupling

• Cohesion – How closely related are the
different responsibilities of a module
• Coupling – How much one module relies
on another
• Goal is low coupling and high cohesion


Single Responsibility Principle (SRP)

• A Class should have only one reason to
change.

Just because you can doesn't mean you should


Responsibiltiy?

• What a class does
• The more a class does, the more likely it
will change
• The more a class changes, the more likely
we will introduce bugs
• Single Responsibility = increased
cohesion


Open-Closed Principle (OCP)

Brain surgery is not needed when putting on a hat.


Liskov Substitution Principle (LSP)

If it looks like a duck, quacks like a duck but
needs batteries - You probably have the
wrong abstraction.

Interface Segregation Principle (ISP)

You want me to plug this in, Where?


Dependency Inversion Principle (DIP)

Would you solder a lamp directly to the
electrical wiring in a wall?


Architecture Smell

• Smell in subsystems
– No subsystems, too little subsystems, too large subsystems
– Too many subsystems
– Cycles in subsystems
• Smells in layers
– No layering
– Upward references (cycles between the layers)
– Breach of layers
– Too many layers
– References between vertical separated layers


Remember

Rather than construction, software is more like gardening –
it is more organic than concrete.
- Pragmatic Programmer


Software Craftsmanship Manifesto


Reach Me @
mnadeem@prokarmasoftech.com
996-663-9709

ProKarma Recognized by Inc. Magazine as the
"Fastest-Growing IT Services Company in
America”

Code Craftsmanship

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Code Craftsmanship

Semelhante a Code Craftsmanship (20)

Code Craftsmanship