Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Code Quality

July 21, 2020

Code Quality

Presented by Irfan (Scrum.org Professional Scrum Developer) at BATC's Scrum Weekly Meetup.

Code is everywhere!
It is not the obvious code on your computer that makes out the majority of code lines that you execute during your daily life. It is the hidden code: In your smart phone (almost obvious), in server farms from Google or Azure, the code running your car's safety feature, in your company's door access system, behind the light switches in your office and even your home, etc. Code is everywhere and we should care that this code works as expected!
In this talk, we will discuss topic about Quality code, that includes on why code rots in presence of change, thoughts on refactoring, and SOLID principle.
The code can be tested, but much better is readable code, it contains less errors, is better maintainable and requires less introduction time for new developers.


July 21, 2020

More Decks by -danny

Other Decks in Technology


  1. Quality Code
    Software Development with Scrum

    View full-size slide

  2. hello…
    Irfan Aris Nurhakim
    Backend Developer Specialist at LinkAja

    View full-size slide

  3. Agenda
    • Code Matters!

    • Code Rots in Presence of Change

    • Counter Measures Against Rotting Code

    • Smells

    • Refactoring

    • SOLID Principle

    View full-size slide

  4. Does Code Matter?
    • 1903 - 0 computers

    • 40 years later

    View full-size slide

  5. Does Code Matter?
    • Where do you lookup the specification of your company’s legacy

    View full-size slide

  6. Bad Code
    for another
    1000 lines!

    View full-size slide

  7. Bad Code is Scary
    • What is bad about this code?

    • Why did this code turn bad?

    • What is good code then?

    View full-size slide

  8. This code turned bad because…
    • Lots of new requirements

    • Lack of time

    • No code readings

    View full-size slide

  9. Code Rots in
    Presence of

    View full-size slide

  10. Broken Window Phenomena
    Day 1
    Day 5
    Day 10

    View full-size slide

  11. Do Not Accumulate Tech Debt
    • Technical Debt is the deferred work
    that must be completed before
    software is considered done

    • Hidden, undone work accumulates

    • it can take many forms

    View full-size slide

  12. Forms of Tech Debt
    • Defects

    • High code complexity

    • Lack of unit tests

    • Highly coupled code

    • Unreadable names and
    • Business Logic in wrong places

    • Too few acceptances

    • High cyclomatics complexity

    • Duplicated code or modules

    • Violating SOLID and other

    View full-size slide

  13. Paying Back Tech Debt
    • Stop generating debt

    • Make a small payment each Sprint

    • Repeat step 2

    View full-size slide

  14. Paying Back Tech Debt
    Software Finance
    Skipping design and refactoring Borrowing money
    Refactoring or redesign Repaying debt
    Slower development due to code smells Paying interest
    Financial metaphor is extremely useful to convince non-tech or financial folks about
    the problem that occur when poor software designs accumulate and grow.

    View full-size slide

  15. Measure Rotting Code/Tech Debt
    • Analyze Code with Metrics

    ✓Module/Method length


    ✓Cyclomatic Complexity

    ✓Code Coverage

    ✓Code Duplication

    • Coding Conventions/Standards

    • Code Reviews

    View full-size slide

  16. Counter Measures Against Rotting Code!
    “What you can’t measure you can’t improve!“ - W. Edwards Deming

    View full-size slide

  17. Grand Redesign in the Sky

    View full-size slide

  18. Boy Scout Rule

    View full-size slide

  19. Continuous, Merciless Refactoring
    • Historic cathedrals are renovated

    • As soon as the work is complete,
    they need to restart

    • Cathedrals in Europa are never seen
    without scaffold

    View full-size slide

  20. Ping Pong Refactoring
    One Developer changes code,

    another one changes it back.

    • Rules are necessary:

    - Balance Collective and Dedicated Code Ownership

    - Develop common rules, conventions and standards

    - Pair Programming

    - Code Reviews

    - Code Readings

    View full-size slide

  21. Quality Code - Refactoring

    View full-size slide

  22. What is Refactoring
    • Smell

    • Refactoring

    • Goal

    View full-size slide

  23. Example of Code Smells
    • Size Smells

    • Not Cleaned up Smells

    • Separation of Data and Functionality

    • Wrong Distribution of Functionality

    • Too Much Coupling

    View full-size slide

  24. Size Smells
    • Large Class

    • Long Method

    • Long Parameter List

    View full-size slide

  25. Not Cleaned Up Smell
    • Duplicated Code

    • Dead Code

    • Speculative Generality

    • Alternative Classes with Different Interfaces

    View full-size slide

  26. Separation of Data and Functionality
    • Primitive Obsession

    • Data Class

    View full-size slide

  27. Wrong Distribution of Functionality
    • Feature Envy

    • Refused Bequest

    View full-size slide

  28. Too Much Coupling
    • Inappropriate Intimacy

    • Message Chain

    • Middle Man

    View full-size slide

  29. Example Refactoring
    Extract Method

    You have a code fragment that can be a grouped together.

    Turn the fragment into a method whose name explains the purpose of the method.

    Used to remove smells like long method or duplicated code.
    void printOwing() {


    //print details

    System.out.println("name: " + _name);

    System.out.println("amount: " + getOutstanding());

    void printOwing() {




    void printDetails(double outstanding) {

    System.out.println("name: " + _name);

    System.out.println("amount: " + getOutstanding());


    View full-size slide

  30. Goals of Refactoring
    The officials goals:

    • Maintainability

    • Readability

    • Extensibility

    The real goal:

    • Safe company’s asset (Code And Team)

    View full-size slide

  31. Thoughts on Refactoring
    • Small steps

    • Two hats

    • Refactoring and Agility

    • Test and Fear

    • Refactoring Test towards clean Tests

    • High Level / Low Level Refactoring

    • Technical debt and Refactoring

    View full-size slide

  32. Clean Code == Quality Code
    “A fool can write code that a computer can understand.
    Good programmers write code that human can understand.“ - Martin Fowler

    View full-size slide

  33. Answer these Questions
    1. Who is going to read your code?

    2. What could be a good metric for code readability?

    View full-size slide

  34. Hotelroom-rule:
    Somebody is cleaning up for you

    View full-size slide

  35. Tools
    • Visual Studio: Dependency Diagrams, Code Analysis, Code Metrics

    • CheckStyle

    • ReSharper/CodeRush/Refactor Pro

    • SonarQube

    View full-size slide

  36. Quality Code - SOLID Design

    View full-size slide

  37. SOLID Design Principles
    Software rapidly rots in presence of change

    • Q: What to do against it?

    • A: Merciless, constant refactoring

    • Q: But towards which direction?

    • A: Towards SOLID Principles

    • A: Towards Clean Code

    • A: Towards/Away from Patterns

    View full-size slide

  38. SOLID - OCP (Open Close Principle)
    Software entities (classes, modules, components, etc.) should be open for
    extension, but closed for modification.

    View full-size slide

  39. SOLID - LSP (Liskov Substitution Principle)
    “Subtypes must be substitutable for their base type” - Barbara Liskov, 1988
    Wherever an object of BaseType is used, an
    instance of SubType could be used instead.

    BaseType b = new SubType();

    View full-size slide

  40. We need a Square!?

    View full-size slide

  41. SOLID - ISP (Inteface Segregation Principle)
    • Not one big interface for all clients, but one interface per kind of client

    • No methods in interface that client does not use

    • No “fat” interfaces

    View full-size slide

  42. SOLID - DIP (Dependency Inversion Principle)
    1. “High-level modules should not depend on low-level modules. Both
    should depend on abstractions”

    2. “Abstractions should not depend on details. Details should depend on

    View full-size slide

  43. SOLID - DIP (Dependency Inversion Principle)
    What’s wrong?

    The button cannot operate other than

    View full-size slide

  44. SOLID - DIP (Dependency Inversion Principle)
    Is this better?

    Not really: What if e.g. Ventilator
    (realizing ButtonServer too) is
    organized in antother layer than
    Layer 2?

    View full-size slide

  45. DIP (Solution)
    Layer 1 (high-level) does not
    depend on Layer 2 (low-level).
    Both depend on abstraction

    Abstraction should not depend
    upon details. Details should
    depend upon abstractions.

    View full-size slide

  46. SOLID - SRP (Single Responsibility Principle)
    • A class has one single responsibility 

    and therefore one reason to change

    • Responsibility: Reason / Axis of Change

    View full-size slide

  47. SOLID - SRP (Single Responsibility Principle)
    • The calculatePay() specified by
    accounting dept, which report to CFO.

    • The reportHours() specified and used
    by human resources dept, which
    reports to COO.

    • The save() specified by DBA, who
    report to CTO.

    View full-size slide

  48. SOLID - SRP (Single Responsibility Principle)
    Shared Algorithm

    View full-size slide

  49. SOLID - SRP (Single Responsibility Principle)

    Separating data from functions. Those 3
    classes share access to EmployeeData,
    which is a simple data structure with no


    View full-size slide

  50. SOLID - SRP (Single Responsibility Principle)
    Developers currently have three classes
    they have to instantiate and track. A
    common solution to this dilemma is to
    use Facade pattern.

    View full-size slide

  51. S.O.L.I.D
    SRP: A class should have only one reason to change
    OCP: Software entities should be open for extension, but closed for modification
    LSP: Subtypes must be substitutable for their base types
    ISP: Clients should not be forced to depend on methods that they do not use
    High-level modules should not depend on low-level modules. Both should depend on

    Abstractions should not depend on details. 

    Details should depend on abstactiongs


    View full-size slide

  52. Further Reading

    View full-size slide

  53. References
    • Software Development with Scrum Handout

    • Clean Code by Robert C. Martin

    • Clean Architecture by Robert C. Martin

    • Clean Code Development by Peter Gfader

    • refactoring.guru

    View full-size slide