Más contenido relacionado
Similar a Code Craftsmanship (20)
Code Craftsmanship
- 1. 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
- 2. ABOUT ME (Nadeem Mohammad)
• Senior Technical Lead
• Web 3.0 COE lead
• ≃ 5 Years with Prokarma
• Two Sons
• Ibraheem
• Imran
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 3. Note
• I would be talking mostly about the following people
works.
Michael Feathers
Martin fowler
Dave Thomas
Grady booch
Ron Jefferies
Ward Cunningham
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 4. AGENDA
• Clean Code, Why?
• Common Terms
• Code Smells
• Design Smells (High Level)
• SOLID Principles (High Level)
• Architecture Smells (High Level)
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 5. 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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 6. Clean Code, Why?
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 7. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 8. Clean Code, Why?
• Good Software == saved more money
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 9. Clean Code, Why?
• Design rot when not carefully maintained
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 10. Clean Code, Why?
• Say yes to Change
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 11. Common Terms
• Code Smells
• Refactoring
• Test Driven Development (TDD)
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 12. 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?
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 13. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 14. Common Terms : TDD
• Does this happen to you
This change
should work
just fine.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 15. Common Terms : TDD
• A new way of programming.
• A new way of thinking
• The Rule
• Only write code to satisfy a failing test
case.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 16. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 17. TDD Cycle
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 18. 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
• ……
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 19. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 20. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 21. 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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 22. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 23. Bloaters: Long Class
• A Class has taken too much
responsibilities, and is modeling more
than one concept.
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 24. Bloaters: Long Class
Delegated the
responsibilities to
different classes
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 25. Bloaters: Long Parameter List
Methods that take too many parameters produce client code that is awkward and difficult to work with.
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 26. Bloaters: Long Parameter List
6 parameters to just 1 parameter
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 27. 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.
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 28. 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
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 29. Data Clumps: Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 30. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 31. Comments : Example
Turn comments into
code
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 32. Comments : Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 33. Dispensables
• They all represent something
unnecessary that should be removed
from the source code
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 34. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 35. Lazy Class : Example
• Pull Up the calculatePostage() method.
• Make the Address class non abstract
• Remove the ShippingAddress Class.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 36. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 37. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 38. Dispensables : Duplicate Code
• Code that is the same, or performs the
same function are showing up in multiple
places within a program.
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 39. Duplicate Code: Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 40. Dispensables : Dead Code
• Code that is no longer used
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 41. Dead Code: Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 42. 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)
The Problem The Solution
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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 43. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 44. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 45. Switch Statements : Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 46. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 47. Temporary fields : Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 48. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 49. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 50. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 51. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 52. Code Smells : Change Preventers
• Smells that hinder changing or further
developing the software
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 53. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 54. Divergent Change : Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 55. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 56. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 57. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 58. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 59. Feature Envy : Example
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 60. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 61. 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()
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 62. 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.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 63. Design Smell
Immobility
Opacity Rigidity
Design
Needless
repetition Smell Fragility
Needless
Viscosity
complexity
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 64. SOLID STUFF
• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 65. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 66. Single Responsibility Principle (SRP)
• A Class should have only one reason to
change.
Just because you can doesn't mean you should
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 67. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 68. Open-Closed Principle (OCP)
Brain surgery is not needed when putting on a hat.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 69. Liskov Substitution Principle (LSP)
If it looks like a duck, quacks like a duck but
needs batteries - You probably have the
wrong abstraction.
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 70. Interface Segregation Principle (ISP)
You want me to plug this in, Where?
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 71. Dependency Inversion Principle (DIP)
Would you solder a lamp directly to the
electrical wiring in a wall?
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 72. 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
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 73. Remember
Rather than construction, software is more like gardening –
it is more organic than concrete.
- Pragmatic Programmer
July 12, 2012 © 2012 ProKarma | All Rights Reserved
Confidential & Proprietary | www.prokarma.com
- 75. Reach Me @
mnadeem@prokarmasoftech.com
996-663-9709
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