Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Introduction PSD
Professional Scrum Developer Java
Who am I? Who are you?
Name From What would I be if I did not end up in IT?
Rules during the course
● Questions?
– Ask!!!!
– Or put them on the board
● Mobile phones
● Laptops
● Breaks
Course content
1. Introduction
2. Scrum explained
3. Scrum courses
4. Agile Testing & TDD
5. Pair Programming
6. Clean Cod...
Scrum explained (5 min.)
● Question:
What is Scrum for you?
● Put in one sentence on a post-it what you think
Scrum is.
Scrum explained
● What are the results? Discuss.
Scrum explained
● Definition:
Scrum is a framework for developing and
sustaining complex products.
Scrum explained: Roles
● Product Owner
– Maximize value of the product
– Manages Product Backlog
– 1 person!
– Prioritizes...
Scrum explained: Roles
● Development Team
– Professionals
– Self organizing
– Everyone is a developer
– Cross functional
–...
Scrum explained: Roles
Scrum explained: Events
● Sprint Planning
– Define work to be performed during the upcoming Sprint.
– Timeboxed: 8 hours f...
Scrum explained: Events
● Sprint Review
– Inspect the increment and adapt Product Backlog
– Invite stakeholders
– Timeboxe...
Scrum explained: Events
● Sprint
– The heart of Scrum
– Timeboxed: Max one month.
– Delivers a “Done”, useable and potenti...
Scrum Explained: Artifacts
● Product Backlog
– Ordered list
– Never complete
– Contains PBI's
– Product Owner is responsib...
Management by walking around
● Round 1
– Pair up: one person will be manager, other the worker
– Simulation: shopping mall...
Management by walking around
● Round 1 evaluation
– How many steps did you take?
– How did you feel? Managers? Workers?
Management by walking around
● Round 2
– No more pairs
– Goal: Take 60 steps
– Each person counts his own steps
– You get ...
Management by walking around
● Round 2 evaluation
– How many steps?
– How did you feel?
https://upload.wikimedia.org/wikip...
Scrum explained: self organizing
● No one (not even the Scrum Master) tells the Development
Team how to turn Product Backl...
Scrum explained: self organizing
Old style Scrum
Team lead assigns tasks Development figures it out ;-)
No such thing as p...
Scrum explained: transparency,
inspect & adapt
● Pillars of empirical process control
– Transparency: be realistic, no hid...
Scrum explained: transparency,
inspect & adapt
Cirkel van Deming
PlanPlan
Inspect
Do
Goal
• Constantly improve
• Deliver f...
Scrum explained: Cross functional
DBA
Testing
Development
Analysis
Operations
DBA
Testing
Development
Analysis
Operations
...
Scrum explained: DoD
“Done”: Means a PBI is
potentially shippable.
Definition of Done (DoD)
● Checklist
● Visible
● Inspec...
Scrum explained: DoD (5min.)
● Answer the following questions:
– What is your Definition of Done?
– Who owns the Definitio...
Scrum explained: DoD (5min.)
● Answer the following questions:
– What is your Definition of Done?
– Who owns the Definitio...
Scrum explained: Estimation
Architect
Team
Customer
When?
During BDUF
Sprint Planning
All the time
How?
Hours
Fibonacci
Be...
Scrum explained: Estimation
● How?
– In group!
– Discussion & Conversation is most important.
– Relative to other things
●...
Scrum explained: Poker planning
http://wendysdogwalking.co.uk/wp-content/uploads/2013/04/dog-on-sofa-300x225.jpg
Scrum explained: Backlog
refinement
● aka Grooming
● Refine PBI's
– Clear and understood
– Estimated
– Broken down in smal...
Scrum explained: Cone of
Uncertainty
www.construx.comInitial Estimate
Product Backlog
Item Estimate
Sprint Backlog
Item Es...
Scrum explained: Waterfall vs.
Scrum
Requirements
BDUF
Development
Testing
Done
Requirements
BDUF
Development
Testing
Done...
Scrum explained: Waterfall vs.
Scrum
D
O
N
E
D
O
N
E
D
O
N
E
D
O
N
E
DO
N
E
● Done is Live
● Collaboration
● Communication...
Scrum explained: Waterfall vs.
Scrum
Visibility Ability to Change
Business Value Risk
Waterfall Scrum
© 1993 - 2013 Scrum....
Scrum explained: Scope,
Resources, Time and Quality
● Project Management Triangle
QUALITY
SCOPE
TIME
RESOURCES
Scrum explained: Where to start?
● Read the Scrum guide!
● Embrace failure.
● Do some assessments
http://www.scrum.org/Ass...
Scrum.org courses
Professional
Scrum
Product Owner
Professional Scrum Foundations
Professional
Scrum Master
Professional
S...
Scrum.org courses
Courses Public and private courses are offered worldwide Assessments Certification
Professional Scrum
Fo...
Scrum.org vs Scrum Alliance
● Scrum.org
– Assessments have more value.
– Each course is the same (doesn't depend on the
tr...
Time for ….
Agile Testing
● Quadrants
Acceptance Testing
Functional Tests
Integration Tests
Exploratory Testing
Scenario Testing
Usabi...
Agile Testing
● Test Pyramids Mike Cohn, Succeeding with Agile
UI
Service
Unit
● Not executed frequently
● Take long time ...
Agile Testing (5min.)
● What is wrong with the following?
UI
Service
Service
Unit
Unit
UI
Service
Unit
UI
Service
Unit
UI
...
TDD (Test Driven Development)
● TDD Cycle
Write Test Watch Test
Fail
Write simplest
code
Run all tests
Refactor
Run all te...
TDD (Test Driven Development)
● Three Laws of TDD
– First: You may not write production code until you have written
a fail...
TDD (Test Driven Development)
● F.I.R.S.T.
– Fast
Tests should be fast.
– Independent
Tests should not depend on each othe...
TDD (Test Driven Development)
Kata String Calculator
● Before you start:
– Try not to read ahead.
– Do one task at a time....
Kata String Calculator (10min.)
Part 1
● Create a simple String calculator with a method
int Add(string numbers)
– The met...
Kata String Calculator (2 min.)
Part 1: Review
● Who has written first a test, before writing the
Calculator class?
● How ...
Kata String Calculator (10 min.)
Part 2
● Allow the Add method to handle an unknown
amount of numbers
● Allow the Add meth...
Kata String Calculator (2 min.)
Part 2: Review
● Who followed TDD Cycle?
● How many tests do you have now?
● Who wrote mul...
Kata String Calculator (10 min.)
Part 3
● Support different delimiters
– to change a delimiter, the beginning of the strin...
Kata String Calculator (2 min.)
Part 3: Review
● Who followed TDD Cycle?
● How do the names of your tests look like?
[Meth...
Kata String Calculator (10 min.)
Part 4:
● Calling Add with a negative number will throw
an exception “negatives not allow...
Kata String Calculator (10 min.)
Part 4: Review
● Who wants to show the result?
http://osherove.com/tdd-kata-1/
Agile Testing: Code Coverage
What does this mean?
Agile Testing: Tools
Time for ….
Time for ….
Pair Programming
Pair Programming
● Roles
– Driver
– Navigator
● Rules
– Pair on everything you'll need to maintain.
– Allow pairs to form ...
Pair Programming
● Advantages
– Higher quality
– Constant knowledge sharing
– Deliver faster
– Faster development
– An ext...
Pair Programming
● Disadvantages
– Are there?
Clean Code
● Michael Feathers, author of Working Effectively
with Legacy Code
“Clean code always looks like it was written...
Time for ….
Clean Code: Boy Scout Rule
“Leave the campground cleaner
than you found it.”
Clean Code: Broken Windows
Theory
The broken windows theory is a criminological theory of the norm-setting and signaling e...
Clean Code: How to measure?
● The # tests?
● The # bugs?
● The # duplicated code?
● The # unused code?
● ...
Clean Code: How to measure?
http://www.osnews.com/story/19266/WTFs_m
Clean Code: Clean Kitchen
3 Michelin sushi chef Saito is a master with the knife
http://youtu.be/robvvJZkfcU
Clean Code: Names
● Use meaningful names
● Use intention – revealing names
● Avoid disinformation
● Use pronounceable name...
Clean Code: Names (15min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code: Na...
Clean Code: Names (10min.)
● Who wants to show the result?
Clean Code: Functions
● Small!
● Do one thing!
● Reading code from Top to Bottom
The stepdown rule
● Arguments
– No flags
...
Clean Code: Functions
Any comments?
Clean Code: Comments
“Don't comment bad code – rewrite it.”
Brian W. Kernighan and P.J. Plaugher
● Explain in code, not in...
Clean Code: Comments (20 min.)
● Checkout the code @
https://github.com/jdewinne/PSDExamples
● Refactor the following code...
Clean Code: Comments (10min.)
● Who wants to show the result?
Clean Code: Formatting
● Vertical formatting
– Lines per file.
– Each class should be max 200 lines!
– Vertical openness
●...
Clean Code: Law of Demeter
● A module should not know about the innards of
the objects it manipulates.
customer.getAddress...
Clean Code: Exceptions
● Use exceptions, instead of return codes.
● Use meaningful exceptions
● Don't return null
● Don't ...
Clean Code: Emergent Architecture
(5min.)
● How does your architecture looks like?
● First design, then implement?
● You t...
Clean Code: Emergent Architecture
● BDUF is waste!
● TDD is design.
● BDD is design.
● Allow your architecture to emerge a...
Clean Code: Technical debt
Code Rots
in Presence
of Change!
Clean Code: Technical debt
Broken
window
Phenomena
Clean Code: Technical debt
● Technical debt = Defects, complexity,
coupled code, lack of testing, duplication, …
● Do NOT ...
Clean Code: SOLID
SRP (Single Responsibility Principle)
DB
Customer
Persistence
System
DB
Customer
Enterprise Java Beans 1...
Clean Code: SOLID
OCP (Open Close Principle)
http://lostechies.com
● Open for Extension
● Closed for
Modification
Clean Code: SOLID
LSP (Liskov Substitution Principle)
Functions that use pointers
to base classes must be
able to use obje...
Clean Code: SOLID
ISP (Interface Segregation Principle)
http://javiernavarromachuca.blogspot.nl/2011/07/interface-segregat...
Clean Code: SOLID
DIP (Dependency Inversion Principle)
http://lostechies.com/derickbailey/2009/02/11/solid-development-pri...
Time for ….
Continuous Delivery
Row 1 Row 2 Row 3 Row 4
0
2
4
6
8
10
12
Column 1
Column 2
Column 3
Source Control
Automated
build
Cont...
Continuous Delivery
Continuous Delivery
Deployment Pipeline provides
constant quick feedback
Continuous
Integration
Middleware
Provisioning
Vi...
Continuous Delivery
Time to Market
Continuous Delivery
Cost Reduction
Continuous Delivery
Building Blocks
Videos: www.cleancoders.com
Videos: Dan Pink
The surprising truth about what motivates us
Videos: Pentagon wars
Tools
●
Management: Jira, Trello, Excel
●
Continuous Integration: Jenkins, Bamboo, Hudson
●
Testing: JUnit, FitNesse, Cucu...
Books
Books
Books
Books
Upcoming SlideShare
Loading in …5
×

Introduction Professional Scrum Developer for Java

4,573 views

Published on

Introduction to the official PSD for Java training from scrum.org. It doesn't cover all topics from the official curriculum, and serves as a intro and teaser to actually follow the official training.

Published in: Technology

Introduction Professional Scrum Developer for Java

  1. 1. Introduction PSD Professional Scrum Developer Java
  2. 2. Who am I? Who are you? Name From What would I be if I did not end up in IT?
  3. 3. Rules during the course ● Questions? – Ask!!!! – Or put them on the board ● Mobile phones ● Laptops ● Breaks
  4. 4. Course content 1. Introduction 2. Scrum explained 3. Scrum courses 4. Agile Testing & TDD 5. Pair Programming 6. Clean Code 7. Continuous Delivery 8. Tools 9. Books
  5. 5. Scrum explained (5 min.) ● Question: What is Scrum for you? ● Put in one sentence on a post-it what you think Scrum is.
  6. 6. Scrum explained ● What are the results? Discuss.
  7. 7. Scrum explained ● Definition: Scrum is a framework for developing and sustaining complex products.
  8. 8. Scrum explained: Roles ● Product Owner – Maximize value of the product – Manages Product Backlog – 1 person! – Prioritizes PBI's ● Scrum Master – Ensures Scrum is understood & enacted – Servant leader – Helps Product Owner, Development Team & Organization – Applies Scrum theory, practices & rules © 1993 - 2013 Scrum.org, All Rights Reserved
  9. 9. Scrum explained: Roles ● Development Team – Professionals – Self organizing – Everyone is a developer – Cross functional – Self Organizing ● Scrum Team – Consists of “Development Team”, “Product Owner” and “Scrum Master” © 1993 - 2013 Scrum.org, All Rights Reserved
  10. 10. Scrum explained: Roles
  11. 11. Scrum explained: Events ● Sprint Planning – Define work to be performed during the upcoming Sprint. – Timeboxed: 8 hours for 4 week sprint – Two parts ● What will we do ● How will we do it – Sprint Goal ● Daily Scrum – Daily 15 minute time boxed event – For the Development Team – No status meeting © 1993 - 2013 Scrum.org, All Rights Reserved
  12. 12. Scrum explained: Events ● Sprint Review – Inspect the increment and adapt Product Backlog – Invite stakeholders – Timeboxed: 4 hours for 4 week sprint ● Sprint Retrospective – Opportunity to inspect how we are working and to adapt – For the Scrum Team – Timeboxed: 3 hours for 4 week sprint http://davidemanske.com/wp-content/uploads/2013/06/SpeedBoatRetrospective-300x128.png http://www.flickr.com/photos/92328289@N02/
  13. 13. Scrum explained: Events ● Sprint – The heart of Scrum – Timeboxed: Max one month. – Delivers a “Done”, useable and potentially releasable product increment – Contains all the other events http://www.flickr.com/photos/gareth_price/
  14. 14. Scrum Explained: Artifacts ● Product Backlog – Ordered list – Never complete – Contains PBI's – Product Owner is responsible ● Sprint Backlog – Set of Product Backlog Items – Plan for delivering Product Increment – Contains Sprint Goal ● Increment – Sum of all PBI's done during a Sprint
  15. 15. Management by walking around ● Round 1 – Pair up: one person will be manager, other the worker – Simulation: shopping mall traffic, by walking from one shop to another – Goal: Take 60 steps – Instructions: ● Go 1 step forward ● Turn 1 step left ● Turn 1 step right ● Stop – Manager counts the number of steps – You get 60 seconds
  16. 16. Management by walking around ● Round 1 evaluation – How many steps did you take? – How did you feel? Managers? Workers?
  17. 17. Management by walking around ● Round 2 – No more pairs – Goal: Take 60 steps – Each person counts his own steps – You get again 60 seconds
  18. 18. Management by walking around ● Round 2 evaluation – How many steps? – How did you feel? https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Fugle,_%C3%B8rns%C3%B8_073.jpg/250px-Fugle,_%C3%B8rns%C3%B8_073.jpg
  19. 19. Scrum explained: self organizing ● No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. ● The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint. ● Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
  20. 20. Scrum explained: self organizing Old style Scrum Team lead assigns tasks Development figures it out ;-) No such thing as people working together Pair programming All communication is done through team lead Direct communication between developers Weekly status meeting, reporting to manager Daily Scrum Team lead is responsible The whole Scrum Team is responsible, including ALL developers.
  21. 21. Scrum explained: transparency, inspect & adapt ● Pillars of empirical process control – Transparency: be realistic, no hidden stuff – Inspection: Look back, measure stuff – Adaption: Be open for changes! ● You can NOT predict the future
  22. 22. Scrum explained: transparency, inspect & adapt Cirkel van Deming PlanPlan Inspect Do Goal • Constantly improve • Deliver faster • Deliver more efficient • Deliver with higher quality Act
  23. 23. Scrum explained: Cross functional DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Testing Analysis Operations TEAM 1 TEAM 2 Testing Development Testing TEAM 3 TEAM 4 Analysis Testing Analysis
  24. 24. Scrum explained: DoD “Done”: Means a PBI is potentially shippable. Definition of Done (DoD) ● Checklist ● Visible ● Inspected & adapted
  25. 25. Scrum explained: DoD (5min.) ● Answer the following questions: – What is your Definition of Done? – Who owns the Definition of Done? – Who or what influences it and how?
  26. 26. Scrum explained: DoD (5min.) ● Answer the following questions: – What is your Definition of Done? – Who owns the Definition of Done? – Who or what influences it and how?
  27. 27. Scrum explained: Estimation Architect Team Customer When? During BDUF Sprint Planning All the time How? Hours Fibonacci Beers ...
  28. 28. Scrum explained: Estimation ● How? – In group! – Discussion & Conversation is most important. – Relative to other things ● Hours??? – Parkinson's law: When an item is finished earlier, the developer will fill remaining time. – Ideal or working hours? Example: Why 16 hours and not 15?
  29. 29. Scrum explained: Poker planning http://wendysdogwalking.co.uk/wp-content/uploads/2013/04/dog-on-sofa-300x225.jpg
  30. 30. Scrum explained: Backlog refinement ● aka Grooming ● Refine PBI's – Clear and understood – Estimated – Broken down in small enough items – Have acceptance criteria Product Owner + Development Team During EACH Sprint Timeboxed As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … As a … I want to … So that …. 3 1 0 8 13 ● ● ●
  31. 31. Scrum explained: Cone of Uncertainty www.construx.comInitial Estimate Product Backlog Item Estimate Sprint Backlog Item Estimate
  32. 32. Scrum explained: Waterfall vs. Scrum Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development
  33. 33. Scrum explained: Waterfall vs. Scrum D O N E D O N E D O N E D O N E DO N E ● Done is Live ● Collaboration ● Communication ● Requirements, Design, Development, Testing – All done in parallel, during Sprint
  34. 34. Scrum explained: Waterfall vs. Scrum Visibility Ability to Change Business Value Risk Waterfall Scrum © 1993 - 2013 Scrum.org, All Rights Reserved
  35. 35. Scrum explained: Scope, Resources, Time and Quality ● Project Management Triangle QUALITY SCOPE TIME RESOURCES
  36. 36. Scrum explained: Where to start? ● Read the Scrum guide! ● Embrace failure. ● Do some assessments http://www.scrum.org/Assessments/Open-Assessments ● Practice, practice, practice ● And practice ● Follow the rules, no exception. © 1993 - 2013 Scrum.org, All Rights Reserved
  37. 37. Scrum.org courses Professional Scrum Product Owner Professional Scrum Foundations Professional Scrum Master Professional Scrum Developer .NET | Java Product Owners Executives Scrum Masters Architects Business Analysts DB Specialists Designers Developers Testers Everyone © 1993 - 2013 Scrum.org, All Rights Reserved
  38. 38. Scrum.org courses Courses Public and private courses are offered worldwide Assessments Certification Professional Scrum Foundations Hands-on training for people looking to start Scrum or reboot a struggling implementation. Professional Scrum Master In-depth training for Scrum Masters and experienced practitioners needing more advanced instruction. Professional Scrum Product Owner Teaches people how to maximize ROI, and optimize the Total Cost of Ownership of products and systems. Professional Scrum Developer Students work as part of a self-organizing team to learn how to use ALM tools and Software development best practices in Scrum. Certification only granted to those that achieve a passing score on the associated assessment
  39. 39. Scrum.org vs Scrum Alliance ● Scrum.org – Assessments have more value. – Each course is the same (doesn't depend on the trainer) – Open for feedback and improvements – Home of Scrum! ● Scrum alliance – Easier to get certified – ...
  40. 40. Time for ….
  41. 41. Agile Testing ● Quadrants Acceptance Testing Functional Tests Integration Tests Exploratory Testing Scenario Testing Usability Testing Test by End User (UAT) Unit Test Module Tests Component Tests Performance & Load Testing Security Testing *ility Testing Technology Facing Business Facing Automated Automated Manual Manual? © 1993 - 2013 Scrum.org, All Rights Reserved Brian Marick, http://bit.ly/PrsMY1
  42. 42. Agile Testing ● Test Pyramids Mike Cohn, Succeeding with Agile UI Service Unit ● Not executed frequently ● Take long time to execute ● Executed frequently ● Take short time to execute
  43. 43. Agile Testing (5min.) ● What is wrong with the following? UI Service Service Unit Unit UI Service Unit UI Service Unit UI Service Unit How do your current tests look like? Explain.
  44. 44. TDD (Test Driven Development) ● TDD Cycle Write Test Watch Test Fail Write simplest code Run all tests Refactor Run all tests Idea?
  45. 45. TDD (Test Driven Development) ● Three Laws of TDD – First: You may not write production code until you have written a failing unit test. – Second: You may not write more of a unit test than is sufficient to fail, and not compiling is failing. – Third: You may not write more production code than is sufficient to pass the currently failing test. ● Keep test clean! ● One Assert per Test. ● Single Concept per Test. Robert C. Martin
  46. 46. TDD (Test Driven Development) ● F.I.R.S.T. – Fast Tests should be fast. – Independent Tests should not depend on each other. – Repeatable Tests should be repeatable in any environment. – Self-Validating Tests should have a boolean output (pass or fail). – Timely Tests should be written before the production code. Robert C. Martin
  47. 47. TDD (Test Driven Development) Kata String Calculator ● Before you start: – Try not to read ahead. – Do one task at a time. The trick is to learn to work incrementally. – Make sure you only test for correct inputs. there is no need to test for invalid inputs for this kata http://osherove.com/tdd-kata-1/
  48. 48. Kata String Calculator (10min.) Part 1 ● Create a simple String calculator with a method int Add(string numbers) – The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1” or “1,2” – Start with the simplest test case of an empty string and move to 1 and two numbers – Remember to solve things as simply as possible so that you force yourself to write tests you did not think about – Remember to refactor after each passing test http://osherove.com/tdd-kata-1/
  49. 49. Kata String Calculator (2 min.) Part 1: Review ● Who has written first a test, before writing the Calculator class? ● How many tests do you have now? ● How many times did you run the test? ● How many times did you refactor your code? http://osherove.com/tdd-kata-1/
  50. 50. Kata String Calculator (10 min.) Part 2 ● Allow the Add method to handle an unknown amount of numbers ● Allow the Add method to handle new lines between numbers (instead of commas). – the following input is ok: “1n2,3” (will equal 6) – the following input is NOT ok: “1,n” (not need to prove it - just clarifying) http://osherove.com/tdd-kata-1/
  51. 51. Kata String Calculator (2 min.) Part 2: Review ● Who followed TDD Cycle? ● How many tests do you have now? ● Who wrote multiple tests at once? ● What about exceptions? http://osherove.com/tdd-kata-1/
  52. 52. Kata String Calculator (10 min.) Part 3 ● Support different delimiters – to change a delimiter, the beginning of the string will contain a separate line that looks like this: “// [delimiter]n[numbers…]” for example “//;n1;2” should return three where the default delimiter is ‘;’ . – the first line is optional. all existing scenarios should still be supported http://osherove.com/tdd-kata-1/
  53. 53. Kata String Calculator (2 min.) Part 3: Review ● Who followed TDD Cycle? ● How do the names of your tests look like? [MethodUnderTest]_[Given]_[Then]? ● How many asserts does one test contain? http://osherove.com/tdd-kata-1/
  54. 54. Kata String Calculator (10 min.) Part 4: ● Calling Add with a negative number will throw an exception “negatives not allowed” - and the negative that was passed. If there are multiple negatives, show all of them in the exception message http://osherove.com/tdd-kata-1/
  55. 55. Kata String Calculator (10 min.) Part 4: Review ● Who wants to show the result? http://osherove.com/tdd-kata-1/
  56. 56. Agile Testing: Code Coverage What does this mean?
  57. 57. Agile Testing: Tools
  58. 58. Time for ….
  59. 59. Time for ….
  60. 60. Pair Programming
  61. 61. Pair Programming ● Roles – Driver – Navigator ● Rules – Pair on everything you'll need to maintain. – Allow pairs to form fluidly rather than assigning partners. – Switch partners when you need a fresh perspective. – Avoid pairing with the same person for more than a day at a time. – Sit confortable, side by side. – Produce code through conversation. Collaborate, don't critique. – Switch driver and navgator role frequently.
  62. 62. Pair Programming ● Advantages – Higher quality – Constant knowledge sharing – Deliver faster – Faster development – An extra pair of eyes – If Bob (the guru) leaves for a round-the-world trip → He Can! – If Rob (the junior) joines the company, he gets up to speed in notime.
  63. 63. Pair Programming ● Disadvantages – Are there?
  64. 64. Clean Code ● Michael Feathers, author of Working Effectively with Legacy Code “Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better” Elegant Efficient Straightforward Simple Direct Well written Meaningfull Clear Beautifull
  65. 65. Time for ….
  66. 66. Clean Code: Boy Scout Rule “Leave the campground cleaner than you found it.”
  67. 67. Clean Code: Broken Windows Theory The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalism on additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments in a well-ordered condition may stop further vandalism and escalation into more serious crime. http://en.wikipedia.org/wiki/Broken_windows_theory ● Just add another “if”. ● Dirty code invites to add more smells. ● Growing method length ● Growing class length ● ...
  68. 68. Clean Code: How to measure? ● The # tests? ● The # bugs? ● The # duplicated code? ● The # unused code? ● ...
  69. 69. Clean Code: How to measure? http://www.osnews.com/story/19266/WTFs_m
  70. 70. Clean Code: Clean Kitchen 3 Michelin sushi chef Saito is a master with the knife http://youtu.be/robvvJZkfcU
  71. 71. Clean Code: Names ● Use meaningful names ● Use intention – revealing names ● Avoid disinformation ● Use pronounceable names ● Avoid encodings – No Hungarian Notation – Member prefixes? ● Use solution domain names ● Use problem domain names ● Pick one word per Concept – No “get”, “retrieve”, “fetch”, ….
  72. 72. Clean Code: Names (15min.) ● Checkout the code @ https://github.com/jdewinne/PSDExamples ● Refactor the following code: Names.java
  73. 73. Clean Code: Names (10min.) ● Who wants to show the result?
  74. 74. Clean Code: Functions ● Small! ● Do one thing! ● Reading code from Top to Bottom The stepdown rule ● Arguments – No flags – As less as possible – Don't use it for returning values ● Have no side effects – “checkPassword” should not create a session ● Exceptions over Error codes ● DRY
  75. 75. Clean Code: Functions Any comments?
  76. 76. Clean Code: Comments “Don't comment bad code – rewrite it.” Brian W. Kernighan and P.J. Plaugher ● Explain in code, not in comments ● Redundant comments :-( ● Misleading comments :-( ● Commented out code :-( ● HTML comments :-( ● Too much information (Do not add the whole specification document)
  77. 77. Clean Code: Comments (20 min.) ● Checkout the code @ https://github.com/jdewinne/PSDExamples ● Refactor the following code: Comments.java
  78. 78. Clean Code: Comments (10min.) ● Who wants to show the result?
  79. 79. Clean Code: Formatting ● Vertical formatting – Lines per file. – Each class should be max 200 lines! – Vertical openness ● Use some white lines ;-) – Vertical Density ● Tightly related lines should be close to each other ● Horizontal formatting – Line length – Each line should max be 120characters long – Horizontal Openness and Density – Indentation ● Team rules!!!!!!!!!
  80. 80. Clean Code: Law of Demeter ● A module should not know about the innards of the objects it manipulates. customer.getAddress().getBillingAddress().getLine1() government.getPresident().getJobDescription().setName()
  81. 81. Clean Code: Exceptions ● Use exceptions, instead of return codes. ● Use meaningful exceptions ● Don't return null ● Don't pass null ● Write the try / catch / finally first ● Use unchecked exceptions
  82. 82. Clean Code: Emergent Architecture (5min.) ● How does your architecture looks like? ● First design, then implement? ● You think also of the future? And have statements like: – It must be scalable – It must be extensible for any feature we can think of – … Discuss!
  83. 83. Clean Code: Emergent Architecture ● BDUF is waste! ● TDD is design. ● BDD is design. ● Allow your architecture to emerge as you develop. ● Think in slices (not in layers)
  84. 84. Clean Code: Technical debt Code Rots in Presence of Change!
  85. 85. Clean Code: Technical debt Broken window Phenomena
  86. 86. Clean Code: Technical debt ● Technical debt = Defects, complexity, coupled code, lack of testing, duplication, … ● Do NOT let it grow! Value Technical debt
  87. 87. Clean Code: SOLID SRP (Single Responsibility Principle) DB Customer Persistence System DB Customer Enterprise Java Beans 1/2 Java Persistence API
  88. 88. Clean Code: SOLID OCP (Open Close Principle) http://lostechies.com ● Open for Extension ● Closed for Modification
  89. 89. Clean Code: SOLID LSP (Liskov Substitution Principle) Functions that use pointers to base classes must be able to use objects of derived classes without knowing it. http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
  90. 90. Clean Code: SOLID ISP (Interface Segregation Principle) http://javiernavarromachuca.blogspot.nl/2011/07/interface-segregation-principle.html ● One interface per kind of client. ● No methods in interface that client does not use. ● No “fat” interfaces.
  91. 91. Clean Code: SOLID DIP (Dependency Inversion Principle) http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ ● “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 abstractions”
  92. 92. Time for ….
  93. 93. Continuous Delivery Row 1 Row 2 Row 3 Row 4 0 2 4 6 8 10 12 Column 1 Column 2 Column 3 Source Control Automated build Continuous integration Automated Testing Automated Deployments Continuous Delivery Automated Provisioning
  94. 94. Continuous Delivery
  95. 95. Continuous Delivery Deployment Pipeline provides constant quick feedback Continuous Integration Middleware Provisioning Virtualized Infrastructure Test ToolingDevelopment Central Monitoring & Logging Application Release Automation O T A P all identical On Demand Environments
  96. 96. Continuous Delivery Time to Market
  97. 97. Continuous Delivery Cost Reduction
  98. 98. Continuous Delivery Building Blocks
  99. 99. Videos: www.cleancoders.com
  100. 100. Videos: Dan Pink The surprising truth about what motivates us
  101. 101. Videos: Pentagon wars
  102. 102. Tools ● Management: Jira, Trello, Excel ● Continuous Integration: Jenkins, Bamboo, Hudson ● Testing: JUnit, FitNesse, Cucumber, DBUnit, TestNG, Greenpepper, Jbehave, Jacoco, Arquillian, ... ● Automated Deployment: Deployit, Nolio, uDeploy ● Collaboration: Confluence, xWiki ● Automated Provisioning: Puppet, Chef, Vagrant, MCollective ● Quality: Sonar ● Build tools: ant, ivy, maven, gradle ● Source safety: subversion, git ● Cloud solutions – Continuous Integration: Cloudbees – Public PAAS: Heroku, OpenShift – Issue Management: Atlassian (Jira), Trello – Don't forget Amazon
  103. 103. Books
  104. 104. Books
  105. 105. Books
  106. 106. Books

×