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

Code Quality

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

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

  3. Agenda • Code Matters! • Code Rots in Presence of

    Change • Counter Measures Against Rotting Code • Smells • Refactoring • SOLID Principle
  4. Does Code Matter? • 1903 - 0 computers • 40

    years later
  5. Does Code Matter? • Where do you lookup the specification

    of your company’s legacy product(s)?
  6. Bad Code Code continues for another 1000 lines!

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

    code? • Why did this code turn bad? • What is good code then?
  8. This code turned bad because… • Lots of new requirements

    • Lack of time • No code readings
  9. Code Rots in Presence of Change!

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

  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
  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
  13. Paying Back Tech Debt • Stop generating debt • Make

    a small payment each Sprint • Repeat step 2
  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.
  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
  16. Counter Measures Against Rotting Code! “What you can’t measure you

    can’t improve!“ - W. Edwards Deming
  17. Grand Redesign in the Sky

  18. None
  19. None
  20. Boy Scout Rule

  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
  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
  23. Quality Code - Refactoring

  24. What is Refactoring • Smell • Refactoring • Goal

  25. Example of Code Smells • Size Smells • Not Cleaned

    up Smells • Separation of Data and Functionality • Wrong Distribution of Functionality • Too Much Coupling
  26. Size Smells • Large Class • Long Method • Long

    Parameter List
  27. Not Cleaned Up Smell • Duplicated Code • Dead Code

    • Speculative Generality • Alternative Classes with Different Interfaces
  28. Separation of Data and Functionality • Primitive Obsession • Data

    Class
  29. Wrong Distribution of Functionality • Feature Envy • Refused Bequest

  30. Too Much Coupling • Inappropriate Intimacy • Message Chain •

    Middle Man
  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()); }
  32. Goals of Refactoring The officials goals: • Maintainability • Readability

    • Extensibility The real goal: • Safe company’s asset (Code And Team)
  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
  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
  35. Answer these Questions 1. Who is going to read your

    code? 2. What could be a good metric for code readability?
  36. Hotelroom-rule: Somebody is cleaning up for you

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

    • CheckStyle • ReSharper/CodeRush/Refactor Pro • SonarQube
  39. Quality Code - SOLID Design Principles

  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
  41. SOLID - OCP (Open Close Principle) Software entities (classes, modules,

    components, etc.) should be open for extension, but closed for modification.
  42. None
  43. None
  44. None
  45. None
  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()
  47. None
  48. None
  49. We need a Square!?

  50. None
  51. None
  52. None
  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
  54. None
  55. None
  56. None
  57. None
  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”
  59. SOLID - DIP (Dependency Inversion Principle) What’s wrong? The button

    cannot operate other than lamp.
  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?
  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.
  62. SOLID - SRP (Single Responsibility Principle) • A class has

    one single responsibility 
 and therefore one reason to change • Responsibility: Reason / Axis of Change
  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.
  64. SOLID - SRP (Single Responsibility Principle) Shared Algorithm

  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?
  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.
  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
  68. None
  69. Further Reading

  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
  71. Thank you!