Code Quality - Speaker Deck

Slide 1

Slide 1 text

Quality Code Software Development with Scrum

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Agenda • Code Matters! • Code Rots in Presence of Change • Counter Measures Against Rotting Code • Smells • Refactoring • SOLID Principle

Slide 4

Slide 4 text

Does Code Matter? • 1903 - 0 computers • 40 years later

Slide 5

Slide 5 text

Does Code Matter? • Where do you lookup the speciﬁcation of your company’s legacy product(s)?

Slide 6

Slide 6 text

Bad Code Code continues for another 1000 lines!

Slide 7

Slide 7 text

Bad Code is Scary • What is bad about this code? • Why did this code turn bad? • What is good code then?

Slide 8

Slide 8 text

This code turned bad because… • Lots of new requirements • Lack of time • No code readings

Slide 9

Slide 9 text

Code Rots in Presence of Change!

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Paying Back Tech Debt • Stop generating debt • Make a small payment each Sprint • Repeat step 2

Slide 14

Slide 14 text

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 ﬁnancial folks about the problem that occur when poor software designs accumulate and grow.

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Grand Redesign in the Sky

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Boy Scout Rule

Slide 21

Slide 21 text

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 scaﬀold

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Quality Code - Refactoring

Slide 24

Slide 24 text

What is Refactoring • Smell • Refactoring • Goal

Slide 25

Slide 25 text

Example of Code Smells • Size Smells • Not Cleaned up Smells • Separation of Data and Functionality • Wrong Distribution of Functionality • Too Much Coupling

Slide 26

Slide 26 text

Size Smells • Large Class • Long Method • Long Parameter List

Slide 27

Slide 27 text

Not Cleaned Up Smell • Duplicated Code • Dead Code • Speculative Generality • Alternative Classes with Diﬀerent Interfaces

Slide 28

Slide 28 text

Separation of Data and Functionality • Primitive Obsession • Data Class

Slide 29

Slide 29 text

Wrong Distribution of Functionality • Feature Envy • Refused Bequest

Slide 30

Slide 30 text

Too Much Coupling • Inappropriate Intimacy • Message Chain • Middle Man

Slide 31

Slide 31 text

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()); }

Slide 32

Slide 32 text

Goals of Refactoring The oﬃcials goals: • Maintainability • Readability • Extensibility The real goal: • Safe company’s asset (Code And Team)

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

Answer these Questions 1. Who is going to read your code? 2. What could be a good metric for code readability?

Slide 36

Slide 36 text

Hotelroom-rule: Somebody is cleaning up for you

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

Tools • Visual Studio: Dependency Diagrams, Code Analysis, Code Metrics • CheckStyle • ReSharper/CodeRush/Refactor Pro • SonarQube

Slide 39

Slide 39 text

Quality Code - SOLID Design Principles

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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()

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

We need a Square!?

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

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”

Slide 59

Slide 59 text

SOLID - DIP (Dependency Inversion Principle) What’s wrong? The button cannot operate other than lamp.

Slide 60

Slide 60 text

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?

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

SOLID - SRP (Single Responsibility Principle) • A class has one single responsibility   and therefore one reason to change • Responsibility: Reason / Axis of Change

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

SOLID - SRP (Single Responsibility Principle) Shared Algorithm

Slide 65

Slide 65 text

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?

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

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 modiﬁcation 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

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Thank you!