Driving Your Team Towards Code Quality

447 views

Published on

Bad code is one of the highest prices we pay, as an industry. Sometimes we write bad code without realizing it and when we do the price to clean it up is too high to pay.

In this session I will show how we can discover and apply object oriented design principles by using practices like unit testing, to get to a higher code quality.

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
447
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • POINT: How to get to code Quality with Unit Testing
  • My name is Florin CorosI live in ClujAnd I am under 35I like to go to ROCK concertsI like to travel with my girl-friendI like to play GO. GO is a game that thought me to look a few steps ahead, which turned to be very useful for me…I tweet quite a lotI am a Software Architect at ISDCI am a big fan of Uncle BobI am one of the cofounders of RABS
  • The main benefit of code quality is that it REDUCE THE COST OF CHANGEChange is certain!Most of the time in our job we change existent code. We change code to add new features, because req change, because we missunderstood something, …The easier is to change it  the easier our job is  the more efficient we are  it costs us lessWe read a lot of code to find where certain behavior is implemented  we need to find our way in the codeRelated benefits - predictability of our changes or of how much it costs to add new features - efficiency: “The only way to go fast is to go well” - wellness and happiness
  • Your managers / clients ask you how much you need to add a new feature. You think about it and say about 3 days. You go at your computer and start coding. You realize it is going to take you 3 weeks
  • Your managers / clients ask you how much you need to add a new feature. You think about it and say about 3 days. You go at your computer and start coding. You realize it is going to take you 3 weeksCHALLENGE: How to get to good quality code with the entire team. Not only by yourself.
  • It is working don’t touch it!Fragile code structureCHALLENGE: How to reach to a code structure which is not fragile and we can change easily and with higher predictability
  • 12’- When does quality pay off?Explain the graphic. Emphasis that in my technique the red is slower at the beginning because of learning curveInteresting aspects about intersection pointPrj finishes before the intersection point: prototype, throw away, PoCTechnical / strategic debt can be done bellow. - Cannot be done above: even if you pay less attention/effort on quality you will still need TOO much time to add a feature and the quality still drops - less quality  slower you areAbove the line we were in the initial example, but without knowing it!CHALLENGE: unaware of having bad code or taking too big technical debt. It takes us by surprise I will show how by doing GOOD unit tests you can keep this under control by having indicators of when your quality dropsBy being on the blue line with our prj most of the times we have done a great job in making our customers/managers not to trust us!It is important to know where you are. As long as you are under the line you may take technical debt but you must be aware! To be able to keep it under controlGood UT can help us knowing when our quality drops and we sleep over the line
  • 16’Ward Cunningham – one of the first who used this metaphor. Google it for the talk on youtubePOINT: balance between spending our efforts on the debt or on actual costs to add new functionality. Essential complexity vsaccidental complexityTechnical Debt is unavoidable. It is not only about strategic debtNo knowledgeable enough with a certain technology or frameworkNot fully understanding of the projectEven the best team knows how the project should have been done only after they have completed itTechnical Debt is being payed by design and refactor. You need to put in the code the learning you are doing while advancing in the projectChallenge: - How can we get to a code structure which is not fragile and we can change? - How do we manage not to get a more tech debt that we can cary? - GO back to the graphic. IT IS IMPORTANT TO KNOW WHERE YOU ARE
  • Functions, Classes, Modules are nothing else that inventions we did in order to be able to deal with the codeWe wanted to be able to ORGANIZE it by following some principles and techniques - we need to be able to FIND where something is implemented - were we need to change - UNDERSTAND how it works - WERE to add new thingKEEP ORDER not MESSComputers don’t need them WE need them!Challenge: How to arrange the code in these? How to balance between how many classes to have for a functionality, how much code in ca class or in a functionHow do we design the code?
  • Design Principles: - SOLID - DRY - Low Coupling High Cohesion - IoC & DIDesign Patterns: - they need the CONTEXT and we need to be able to tweak them for the problem we need to solve - inheritance vs composition - Decorator vs inheritance - when is inheritance OK  TemplateMethod pattern
  • 29’You need to make a clear distinction between an integration tests, and a unit testIt can be written easily and runs quickly.It’s fully automated, trustworthy, readable, and maintainable.Quality Attributes of Good Unit TestsReadableMaintainableTrustworthy
  • All the discussion about whether the design principles and design patterns are being followed are summarized to ONE question
  • Flying people into space presents interesting challenges to engineersand astronauts, one of the more difficult being how to make sure theastronaut is ready to go into space and operate all the machinery. A fullintegration test for a space shuttle would require being in space, and that’sobviously not a safe way to test astronauts. That’s why NASA has fullsimulators that mimic the surroundings of a space shuttle’s control deck,which removes the external dependency of having to be in outer space.
  • SOLID at workDesign patterns at workEach time you depend on something on which you have no control in your test you are doing an integration test!Integration tests are to be avoided because: - hard to write & maintain, depend on configurations  HIGH COSTS - not knowing where the cause of failure is (which code, is it bad config?), no benefits to your code quality  LOW BENEFITS
  • SOLID at workDesign patterns at workEach time you depend on something on which you have no control in your test you are doing an integration test!Integration tests are to be avoided because: - hard to write & maintain, depend on configurations  HIGH COSTS - not knowing where the cause of failure is (which code, is it bad config?), no benefits to your code quality  LOW BENEFITS
  • SOLID at workDesign patterns at workEach time you depend on something on which you have no control in your test you are doing an integration test!Integration tests are to be avoided because: - hard to write & maintain, depend on configurations  HIGH COSTS - not knowing where the cause of failure is (which code, is it bad config?), no benefits to your code quality  LOW BENEFITS
  • 45’
  • 46’ – 48’
  • Broken windows syndrome for green module (team)
  • 50’Story MariaReusability – every class in production code is exercised in at least two context: production and testExtensibility – is assured by the seams we need to introduce in our code to make it testable. These become extension pointMaintainability – low coupling high cohesionIt simplifies in keeping the balance between how big a class should be vs how many classes should we have. See Juval chart- experienced this in a few teams and I’ve founded easier- Easier to review and spot a design flaw- Easier to cover this in peer reviews by developers that do not master (don’t have enough experience) with OOD- EASIER RULES TO FOLLOW
  • 52’Team structureApplication Infrastructure is important for making the link between the the arc and dev - it has the mechanisms that assure that the size and complexity of the project can be managed - it depends on the team structure as wellCode coverage targets are a very important tool to force logic to stay in appropriate layers. Example logic in the view (presentation)Clean Code:Learn how production code should be writtenlearn to care about the codeCLUB (Code Like Uncle Bob): “No one should be allowed to write any production code without reading this book”Learn what Good Unit Testing is  Go to a class training, hire a mentor…Unit Testing – Two edged sword: ‘You can cut yourself if you don’t master it well, but if you do you can wanders if you do”Understand why good unit tests are importantLearn the main techniques to refactor the production code to make it testable
  • Say about I TAKE
  • Driving Your Team Towards Code Quality

    1. 1. itcampro@ itcamp13# Premium conference on Microsoft technologiesDriving Your Team TowardsCode QualityFlorin Coroswww.rabs.roflorin.coros@rabs.ro@florincoroswww.florincoros.wordpress.com
    2. 2. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesHuge thanks to our sponsors!
    3. 3. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesAbout meRABS, Co-FounderISDC, Software Architect@florincoros
    4. 4. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesInspired
    5. 5. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesWhy Code Quality?
    6. 6. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesChange Predictability- How much time to add this new small feature?- Hm… let’s see… so it is very similar with what we have, right? Hm… about 2 to 3 days I think...
    7. 7. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesChange Predictabilitycrap…. I have to change much more than I thought … No way I can do this by tomorrow… I think I’m going to work on this 2 to 3 weeks maybe
    8. 8. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesIt works. Don’t touch it!
    9. 9. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Design vs Bad Designhttp://martinfowler.com/bliki/DesignStaminaHypothesis.html
    10. 10. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesTechnical Debt
    11. 11. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesFunctions, Classes, Modules
    12. 12. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesDesigns1 23 4http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/ARC201
    13. 13. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesDesignshttp://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/ARC201
    14. 14. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesDesign Principles & Design Patterns
    15. 15. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesKnowledge vs ExperienceYou learn the rules of chess in a few hoursYou become a good chess player after yearsof practicingYou need to practice with strong opponentsYou need to go to tournaments to meetstrong opponentsYou learn the rules of GO in a few minutesYou become a good GO player after manyyears of practicingSame as at chess, but much more exerciseis needed because it is more complex
    16. 16. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesAlternative: GOOD Unit TestsIt is very smallIt can be written easily and runsquicklyIt’s readable, maintainable,trustworthy and fully automatedIt should run in isolationIt should test ONE thingIf it fails you should know exactlywhere the bug is
    17. 17. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesHow does GOOD UT get us there?OOD PrinciplesSOLIDDRYIoC & DILowCouplingHigh Coherence…..…Design PatternsCompositeChain Of ResponsibilityDecorator…….Can you TEST it?Good EnoughGOOD Unit TestsSmallIn IsolationTest ONE ThingEasy to implement
    18. 18. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Tests - easy to writeless than 5 minutes to implementfew lines of code. Less than 10 -15see from a glimpse what the test checks
    19. 19. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Tests - Run in IsolationIsolate the code under testfrom the rest of your system,by creating seams, to be ableto plug fakes (stubs & mocks)which you can control inyour test“There is no object-orientedproblem that cannot besolved by adding a layer ofindirection, except, ofcourse, too many layers ofindirection.”
    20. 20. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Test - test ONE thingCheck only ONE thing inyour tests. If the test failsyou know exactly where theproblem is. You do not needto do step-by-stepdebugging
    21. 21. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Tests - not integration testsBCf()g()h()h’()Depend on abstractions not on implementationdetails (DIP)Use IoC for instantiating objects, or Factorydesign patternsVisible dependencies for our classesLow coupling and high coherenceExtensibility, Reusability (OCP)Design PatternsIntegration tests:HIGH COSTS & LOW BENEFITS
    22. 22. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Tests - not integration testsScreenKeyboardtranslate()write()read()Depend on abstractions not on implementationdetails (DIP)Use IoC for instantiating objects, or Factorydesign patternsVisible dependencies for our classesLow coupling and high coherenceExtensibility, Reusability (OCP)Design PatternsIntegration tests:HIGH COSTS & LOW BENEFITS
    23. 23. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesGood Unit Tests - not integration testsITextOutputITextInputtranslate()write()read()Depend on abstractions not on implementationdetails (DIP)Use IoC for instantiating objects, or Factorydesign patternsVisible dependencies for our classesLow coupling and high coherenceExtensibility, Reusability (OCP)Design PatternsIntegration tests:HIGH COSTS & LOW BENEFITS
    24. 24. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesEliminate circular dependenciesA simple designed systemcannot be largeIt has low coupling and highcoherence
    25. 25. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesEliminate circular dependenciesA system is large and too rigid tochange if it has circulardependenciesIt has high coupling and lowcoherence
    26. 26. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesContinuous & Small CyclesCODEUNITTESTREFACTORShort cycles between unit test andproduction codeRefactor in early stage, at lower costsSame principle for test first or forcode first
    27. 27. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesCode Coverage History9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29Infrastructure 30 35 40 41 60 70 70 75 75 76 79 78 80 68 70 71 65 71 65 70 68CoreServices 60 75 80 81 78 80 81 78 75 81 89 78 75 80 68 75 80 78 81 79 80Module 1 0 30 40 45 50 60 58 60 57 55 60 58 60 61 57 55 50 48 42 57 59Module 2 50 60 65 70 68 67 75 77 75 74 73 75 77 75 73 75 72 74 75 77 750102030405060708090100%BlocksCovered
    28. 28. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesIs it easier?OOD PrinciplesDesign Patterns Can you TEST it?ReusabilityExtensibilityMaintainabilityGOOD Unit TestsBad Design Smells with Good TestsCode at wrong level of abstractionClass with more responsibilitiesBase classes depending on their derivatesArtificial couplingFeature envyPolymorphism over if/else or switch/casePoor coheranceViolates SOLIDShould have used certain design patternTest is difficult to understand. It is very large(more than 20 lines)Checks on more than ONE thingDoes not run in isolationAre not following the naming conventions
    29. 29. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesHow to do it?ArchitectureApp SoftwareInfrastructureVertical SliceReviewGood UTRefactorWHOLE team is doing Good Unit Testing!DeliverFunctionalityDeliverFunctionalityDeliverFunctionalityDefine code coveragetargets
    30. 30. itcampro@ itcamp13# Premium conference on Microsoft technologiesArchitecture &Best PracticesThank you!

    ×