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.

Transcript

1. Clean Code Developer A way to better code Session 05 https://github.com/mp911de/CCD
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