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

Code Quality

-danny
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.

-danny

July 21, 2020
Tweet

More Decks by -danny

Other Decks in Technology

Transcript

  1. Quality Code
    Software Development with Scrum

    View Slide

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

    View Slide

  3. Agenda
    • Code Matters!

    • Code Rots in Presence of Change

    • Counter Measures Against Rotting Code

    • Smells

    • Refactoring

    • SOLID Principle

    View Slide

  4. Does Code Matter?
    • 1903 - 0 computers

    • 40 years later

    View Slide

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

    View Slide

  6. Bad Code
    Code
    continues
    for another
    1000 lines!

    View Slide

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

    • Why did this code turn bad?

    • What is good code then?

    View Slide

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

    • Lack of time

    • No code readings

    View Slide

  9. Code Rots in
    Presence of
    Change!

    View Slide

  10. Broken Window Phenomena
    Day 1
    Day 5
    https://blog.gfader.com/2011/10/broken-window-theory-in-real-world.html
    Day 10

    View 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 Slide

  12. Forms of Tech Debt
    • Defects

    • High code complexity

    • Lack of unit tests

    • Highly coupled code

    • Unreadable names and
    algorithms
    • Business Logic in wrong places

    • Too few acceptances

    • High cyclomatics complexity

    • Duplicated code or modules

    • Violating SOLID and other
    principles

    View Slide

  13. Paying Back Tech Debt
    • Stop generating debt

    • Make a small payment each Sprint

    • Repeat step 2

    View 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 Slide

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

    ✓Module/Method length

    ✓Coupling/Cycles

    ✓Cyclomatic Complexity

    ✓Code Coverage

    ✓Code Duplication

    • Coding Conventions/Standards

    • Code Reviews

    View Slide

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

    View Slide

  17. Grand Redesign in the Sky

    View Slide

  18. View Slide

  19. View Slide

  20. Boy Scout Rule

    View Slide

  21. Continuous, Merciless Refactoring
    • Historic cathedrals are renovated
    constantly

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

    • Cathedrals in Europa are never seen
    without scaffold

    View Slide

  22. 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 Slide

  23. Quality Code - Refactoring

    View Slide

  24. What is Refactoring
    • Smell

    • Refactoring

    • Goal

    View Slide

  25. Example of Code Smells
    • Size Smells

    • Not Cleaned up Smells

    • Separation of Data and Functionality

    • Wrong Distribution of Functionality

    • Too Much Coupling

    View Slide

  26. Size Smells
    • Large Class

    • Long Method

    • Long Parameter List

    View Slide

  27. Not Cleaned Up Smell
    • Duplicated Code

    • Dead Code

    • Speculative Generality

    • Alternative Classes with Different Interfaces

    View Slide

  28. Separation of Data and Functionality
    • Primitive Obsession

    • Data Class

    View Slide

  29. Wrong Distribution of Functionality
    • Feature Envy

    • Refused Bequest

    View Slide

  30. Too Much Coupling
    • Inappropriate Intimacy

    • Message Chain

    • Middle Man

    View Slide

  31. 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() {

    printBanner();

    //print details

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

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

    }
    void printOwing() {

    printBanner();

    printDetails(getOutstanding());

    }

    void printDetails(double outstanding) {

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

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

    }

    View Slide

  32. Goals of Refactoring
    The officials goals:

    • Maintainability

    • Readability

    • Extensibility

    The real goal:

    • Safe company’s asset (Code And Team)

    View Slide

  33. 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 Slide

  34. 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 Slide

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

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

    View Slide

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

    View Slide

  37. View Slide

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

    • CheckStyle

    • ReSharper/CodeRush/Refactor Pro

    • SonarQube

    View Slide

  39. Quality Code - SOLID Design
    Principles

    View Slide

  40. 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 Slide

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

    View Slide

  42. View Slide

  43. View Slide

  44. View Slide

  45. View Slide

  46. 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();
    b.doSomething()

    View Slide

  47. View Slide

  48. View Slide

  49. We need a Square!?

    View Slide

  50. View Slide

  51. View Slide

  52. View Slide

  53. 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 Slide

  54. View Slide

  55. View Slide

  56. View Slide

  57. View Slide

  58. 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
    abstractions”

    View Slide

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

    The button cannot operate other than
    lamp.

    View Slide

  60. 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 Slide

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

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

    View Slide

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

    and therefore one reason to change

    • Responsibility: Reason / Axis of Change

    View Slide

  63. 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 Slide

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

    View Slide

  65. SOLID - SRP (Single Responsibility Principle)
    Solutions

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

    Downside?

    View Slide

  66. 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 Slide

  67. 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
    DIP:
    High-level modules should not depend on low-level modules. Both should depend on
    abstractions. 

    Abstractions should not depend on details. 

    Details should depend on abstactiongs

    A

    View Slide

  68. View Slide

  69. Further Reading

    View Slide

  70. 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 Slide

  71. Thank you!

    View Slide