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.

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