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
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
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
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.
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()
49. We need a Square!?
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
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
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!