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

Clean Code Developer Blue Grade

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. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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, ...)
  11. 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
  12. 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
  13. 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