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

Clean Code Developer Blue Grade

C5f6e8dffbb19acf405198c8fb917337?s=47 Mark Paluch
September 02, 2014

Clean Code Developer Blue Grade

Learn the principles and practices of Clean Code Development. This is the second session in the Clean Code Development track. Go on with the next level and dig into Clean Code.


Mark Paluch

September 02, 2014

More Decks by Mark Paluch

Other Decks in Programming


  1. Clean Code Developer A way to better code Session 05

  2. Agenda • Blue Grade

  3. Blue Grade

  4. Blue Grade • Principles • Design and implementation do not

    overlap • Implementation reflects design • You ain‘t gonna need it (YAGNI) • Practices • Continuous Delivery • Iterative development • Component-oriented development • Test first
  5. Design and implementation do not overlap • Design and implementation

    model drift apart • Don‘t repeat yourself • Keep information on the right level/the right place
  6. Good design model • Contains component design („Black Boxes“) •

    Does not contain implementation details • Architects/Dev-Leads do component design • Devs implement components with no need of architecture design • Structure cannot be changed simply by implementation
  7. Implementation reflects design • Do you recognize the design model

    within your implementation? • Code is organized according design model • Lessons learned from implementation may affect design model
  8. You ain‘t gonna need it (YAGNI) • The most simple

    and most violated discipline • Why? • Unclear requirements spec • Inaccurate products should compensate inaccurate requirements • „Immateriality“ of code is used for creating fat code to be flexible
  9. Violating YAGNI leads to... • Unnecessary Implementations • Loss of

    quality (this isn‘t used by anyone, so why fix it) • Do you really need it? Event if effort is minimal • Implement only, what requirements and quality demand
  10. Continuous Delivery

  11. Continuous Delivery • Continuous integration are first steps • Practice

    releases, automate them • Keep QA efforts low – automate tests, where possible (it‘s possible in 99,5%) • Automation is the key in reducing „human mistakes“ • One button deployments • Example: Flickr deploys multiple times to production a day
  12. Iterative development • Why iterations? • Software is way too

    complex for one-shot • Multiple „releases“ provide fundament for regular feedbacks • Learn from iteration to iteration • Iterations between 2 and 4 weeks are optimal
  13. Component-oriented development • Code lines build methods, methods are in

    classes. And classes? • Components are the level between classes and application • Components communicate with other components
  14. Component-oriented development • Contract-first design: API • Btw: Every class

    is an API • Components see each other as black boxes • Isolate components, where possible (e.g. own projects, artifacts, ...)
  15. Test first (TDD) • Guarantees your code to be testable

    • YAGNI has no chance • Real, consumer based development • Interface/component specs are no longer passive, they are real life code
  16. Laws of Test-driven development 1.You must write a test, that

    fails (compilation failure is as well a failure) 2.You are only allowed to write as much test code that is necessary to let your test fail 3.You are only allowed to write as much production code that is necessary to let your test pass. Start over with 1
  17. Test first (TDD) • Life-insurance for changes • Keeps code

    under your control • Reduction of QA • Write it once, use it multiple times • Avoid risk of tight coupling • Initial effort a bit higher, but it pays off
  18. Image Credits Table of Contents: © by Michael Kappel http://michaelkappel.com

    Bands: © by Alexander Herzog