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

The State of Quality - Making life hard for bugs

The State of Quality - Making life hard for bugs

4Developers - Poznan - April 2012
-
Code Quality (aka Internal Quality) is so hard to define that if you ask about it to 10 programmers you'll surely end with 10 different answers. While there are already many formal definitions, this talk tells the story of how our team improved the quality of code and reduce the number of bugs. The talk focus on the practical side, showing several simple techniques to keep bugs out of your code.

Uberto Barbini

April 18, 2012
Tweet

More Decks by Uberto Barbini

Other Decks in Programming

Transcript

  1. About me Uberto Barbini Software artisan Agile enthusiast. @ramtop +10

    years experience in project leading. Currently Teamleader and TechArchitect for Vodafone editorial and backend products. Wednesday, April 18, 12
  2. The State of the Quality Making life hard for bugs

    DEVELOPERS - April 2012 - Poznan Wednesday, April 18, 12
  3. greenfield n : land (as a potential industrial site) not

    previously developed or polluted. Wednesday, April 18, 12
  4. greenfield n : land (as a potential industrial site) not

    previously developed or polluted. If all your projects are like this you may be not interested in this talk Wednesday, April 18, 12
  5. My project are more like this... brownfield n : abandoned,

    idled or underused industrial and commercial facility where expansion or redevelopment is complicated by real or perceived environmental contamination. Wednesday, April 18, 12
  6. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Wednesday, April 18, 12
  7. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Wednesday, April 18, 12
  8. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Wednesday, April 18, 12
  9. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Wednesday, April 18, 12
  10. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Because there were many bugs still open Wednesday, April 18, 12
  11. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Because there were many bugs still open Why were there bugs still open? Wednesday, April 18, 12
  12. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Because there were many bugs still open Why were there bugs still open? Because we take more time to close bugs Wednesday, April 18, 12
  13. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Because there were many bugs still open Why were there bugs still open? Because we take more time to close bugs Why are we taking more time to close bugs? Wednesday, April 18, 12
  14. A tale about Quality Once upon a time everything was

    easy, now everything takes ages to complete. Why we cannot honor estimates anymore? Because we don’t start in time Why we didn’t start in time? Because there were many bugs still open Why were there bugs still open? Because we take more time to close bugs Why are we taking more time to close bugs? Because... Wednesday, April 18, 12
  15. Bugs had became harder to find! What if we change

    the background? Wednesday, April 18, 12
  16. Bugs had became harder to find! What if we change

    the background? Wednesday, April 18, 12
  17. Bugs had became harder to find! What if we change

    the background? Can you spot the insect now? Wednesday, April 18, 12
  18. We need to make bugs more evident! There are two

    ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it. C.A.R. Hoare Wednesday, April 18, 12
  19. Reshape your code! What do we want to get rid

    of? Wednesday, April 18, 12
  20. TMandelbrot = class .... public Par: TMandParameters; Colors : TColorize;

    constructor Create(ABitmap: TBitmap; const ProdVers: string); destructor Destroy; override; procedure Prepare( AMandelSet: TMandelSet; AColors: TColorize ); procedure Render( UpdatingInfo: boolean = true ); function AlgMndFlt( CR, CI :Extended ): extended; function GetPercentDrawn: Extended; procedure UpdateInfo; procedure Redraw; procedure DoProgress( Progress: Extended = -1 ); procedure DoFilter( AFilter: TFilterKind; KeepProgr: Boolean = True); procedure RestoreFilter; procedure StoreFilter; procedure MandelSetDefault( var AMandelset: TMandelSet ); property Info: TMandelInfo read FInfo; published property ProgressTimer: Cardinal read FTimer write SetTimer; property OnProgress: TProgrEvent read FOnProgress write SetOnProgress; end; http://fractalforge.cvs.sourceforge.net/viewvc/fractalforge/fractalforge/Mandelbrot.pas?view=markup Wednesday, April 18, 12
  21. TMandelbrot = class .... public Par: TMandParameters; Colors : TColorize;

    constructor Create(ABitmap: TBitmap; const ProdVers: string); destructor Destroy; override; procedure Prepare( AMandelSet: TMandelSet; AColors: TColorize ); procedure Render( UpdatingInfo: boolean = true ); function AlgMndFlt( CR, CI :Extended ): extended; function GetPercentDrawn: Extended; procedure UpdateInfo; procedure Redraw; procedure DoProgress( Progress: Extended = -1 ); procedure DoFilter( AFilter: TFilterKind; KeepProgr: Boolean = True); procedure RestoreFilter; procedure StoreFilter; procedure MandelSetDefault( var AMandelset: TMandelSet ); property Info: TMandelInfo read FInfo; published property ProgressTimer: Cardinal read FTimer write SetTimer; property OnProgress: TProgrEvent read FOnProgress write SetOnProgress; end; http://fractalforge.cvs.sourceforge.net/viewvc/fractalforge/fractalforge/Mandelbrot.pas?view=markup Fractal Forge has been my first serious tentative with Object Oriented programming. It’s written in Object Pascal (Borland Delphi). This class is 1751 lines of code. Wednesday, April 18, 12
  22. TMandelbrot = class .... public Par: TMandParameters; Colors : TColorize;

    constructor Create(ABitmap: TBitmap; const ProdVers: string); destructor Destroy; override; procedure Prepare( AMandelSet: TMandelSet; AColors: TColorize ); procedure Render( UpdatingInfo: boolean = true ); function AlgMndFlt( CR, CI :Extended ): extended; function GetPercentDrawn: Extended; procedure UpdateInfo; procedure Redraw; procedure DoProgress( Progress: Extended = -1 ); procedure DoFilter( AFilter: TFilterKind; KeepProgr: Boolean = True); procedure RestoreFilter; procedure StoreFilter; procedure MandelSetDefault( var AMandelset: TMandelSet ); property Info: TMandelInfo read FInfo; published property ProgressTimer: Cardinal read FTimer write SetTimer; property OnProgress: TProgrEvent read FOnProgress write SetOnProgress; end; http://fractalforge.cvs.sourceforge.net/viewvc/fractalforge/fractalforge/Mandelbrot.pas?view=markup Fractal Forge has been my first serious tentative with Object Oriented programming. It’s written in Object Pascal (Borland Delphi). This class is 1751 lines of code. It works but it is the most unSOLID possible design. Can you spot the issues? Wednesday, April 18, 12
  23. Duplicated intents This code is repeated several times in different

    services. The intent is the same, that is use cache with a specific logic. But every time the lines in red are different. What can we do? Wednesday, April 18, 12
  24. Cons: Slightly more code (if only 1 occurrence) Not the

    most familiar of code. Pros: Remove of cache access logic from main class. Impossible to forget a step. Possible to change the logic for testing Solution: Template Pattern in inner class. Wednesday, April 18, 12
  25. Avoid undetermined results by changing interface Here it’s not clear

    what will happen Now it’s clear what’s the goal Wednesday, April 18, 12
  26. Which one does resemble your code better? A well cut

    code has no interstices Wednesday, April 18, 12
  27. Design clean interfaces I thought of objects being like biological

    cells and/or individual computers on a network, only able to communicate with messages. Alan Key Don’t think Methods, think Messages Wednesday, April 18, 12
  28. There is no calling order Easy to test and mock

    Hollywood Principle Wednesday, April 18, 12
  29. Reduce the information passed around Immutable objects Enum or Method

    instead of integer and strings Wednesday, April 18, 12
  30. Extract algorithms with Strategy and Functions There was a very

    long and complex method here... Wednesday, April 18, 12
  31. Fractal architecture 1. Inject the Dependencies 2. Hide the Objects

    behind Interfaces 3. Call Functions and Continuations Wednesday, April 18, 12
  32. Fractal architecture 1. Inject the Dependencies 2. Hide the Objects

    behind Interfaces 3. Call Functions and Continuations 4. Pass Immutable Value Objects Wednesday, April 18, 12
  33. Fractal architecture 1. Inject the Dependencies 2. Hide the Objects

    behind Interfaces 3. Call Functions and Continuations 4. Pass Immutable Value Objects 5. Go one level down and repeat Wednesday, April 18, 12
  34. The power of mocks All dependencies passed on the constructor

    using interfaces Test complex object for behavior not for state Wednesday, April 18, 12
  35. How to operate 1. Start with a God class to

    split Wednesday, April 18, 12
  36. How to operate 1. Start with a God class to

    split 2. Write a test for it with near 100% coverage Wednesday, April 18, 12
  37. How to operate 1. Start with a God class to

    split 2. Write a test for it with near 100% coverage 3. Mock all external relations Wednesday, April 18, 12
  38. How to operate 1. Start with a God class to

    split 2. Write a test for it with near 100% coverage 3. Mock all external relations 4. Extract methods basically everywhere Wednesday, April 18, 12
  39. How to operate 1. Start with a God class to

    split 2. Write a test for it with near 100% coverage 3. Mock all external relations 4. Extract methods basically everywhere 5. Aggregate and move some methods and external relation to collaborators Wednesday, April 18, 12
  40. How to operate 1. Start with a God class to

    split 2. Write a test for it with near 100% coverage 3. Mock all external relations 4. Extract methods basically everywhere 5. Aggregate and move some methods and external relation to collaborators 6. Repeat again on collaborators until clean Wednesday, April 18, 12
  41. Going Modular Module Domain Service Adapter Module Module Platform Service

    Service Uncle Bob's "Package Cohesion Principles" are: REP: The Release Reuse Equivalency Principle -- The granule of reuse is the granule of release. CCP: The Common Closure Principle -- Classes that change together are packaged together. CRP: The Common Reuse Principle -- Classes that are used together are packaged together. Wednesday, April 18, 12
  42. Project complexity Time to develop a feature OOP+FP Functional P

    Object Oriented P Procedural P Wednesday, April 18, 12
  43. Project complexity Time to develop a feature OOP+FP Functional P

    Object Oriented P Procedural P Statistic data sample: 1 interview to myself Wednesday, April 18, 12