Clean Code I - Best Practices
•Download as PPTX, PDF•
46 likes•15,049 views
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs. Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too. Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare. Presentation dates and locations: 2015-10-03 Silicon Valley Code Camp, San Jose, CA 2015-06-27 SoCal Code Camp - San Diego, CA 2014-11-14 SoCal Code Camp - Los Angeles, CA 2014-10-18 Desert Code Camp - Chandler, AZ 2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Clean Code I - Best Practices
Similar to Clean Code I - Best Practices (20)
More from Theo Jungeblut
More from Theo Jungeblut (15)
Recently uploaded
Recently uploaded (20)
Clean Code I - Best Practices
- 1. Evergreen Valley College, Oct. 3rd, 2015 Clean Code I Best Practices
- 2. Theo Jungeblut • Director Customer Success at AppDynamics in San Francisco • Coder & software craftsman by night, first time dad and house builder • Architects decoupled solutions & crafts maintainable code to last • Worked in healthcare and factory automation, building mission critical applications, framework & platforms • Degree in Software Engineering and Network Communications • Enjoys cycling, running and eating theo@designitright.net www.designitright.net
- 3. We are hiring! http://www.appdynamics.com/ careers
- 4. Your feedback is important! http://speakerrate.com/speakers/18667-theo-jungeblut
- 5. Where to get the Slides http://www.slideshare.net/theojungeblut
- 6. Overview • Why Clean Code • Clean Code Developer Initiative • Principles and Practices • Code Comparison • Q&A
- 7. Does writing Clean Code make us more efficient?
- 8. The only valid Measurement of Code Quality
- 9. What is Clean Code?
- 10. Clean Code is maintainable Source code must be: • readable & well structured • extensible • testable
- 12. The “Must Read”-Book(s) by Robert C Martin A Handbook of Agile Software Craftsmanship “Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees.”
- 13. Code Maintainability * Principles Patterns Containers Why? How? What? Extensibility Clean Code Tool reuse * from: Mark Seemann’s “Dependency Injection in .NET” presentation Bay.NET 05/2011
- 14. Clean Code Developer Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/
- 15. The 4 values of the CCD initiative • Correctness • Evolvability • Production Efficiency • Continuous Improvement http://blogs.telerik.com/justteam/posts/13-05-16/clean-code-developer-school by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 16. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 1st Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 17. Keep it simple, stupid (KISS)
- 18. KISS-Principle – “Keep It Simple Stupid” http://blogs.smarter.com/blogs/Lego%20Brick.jpg by Kelly Johnson
- 19. The Power of Simplicity http://www.geekalerts.com/lego-iphone/ Graphic by Nathan Sawaya courtesy of brickartist.com Graphic by Nathan Sawaya courtesy of brickartist.com
- 20. Chaos build from simplicity Graphic by Nathan Sawaya courtesy of brickartist.com
- 22. Don’t repeat yourself (DRY) by Andy Hunt and Dave Thomas in their book “The Pragmatic Programmer” // Code Copy and Paste Method public Class Person { public string FirstName { get; set;} public string LastName { get; set;} public Person(Person person) { this.FirstName = string.IsNullOrEmpty(person.FirstName) ? string.Empty : string.Copy(person.FirstName); this.LastName = string.IsNullOrEmpty(person.LastName) ? string.Empty : string.Copy(person.LastName); } public object Clone() { return new Person(this); } } // DRY Method public Class Person { public string FirstName { get; set;} public string LastName { get; set;} public Person(Person person) { this.FirstName = person.FirstName.CloneSecured(); this.LastName = person.LastName.CloneSecured(); } public object Clone() { return new Person(this); } } public static class StringExtension { public static string CloneSecured(this string original) { return string.IsNullOrEmpty(original) ? string.Empty : string.Copy(original); } }
- 23. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 1st Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 24. Clean Code Developer – 2nd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/
- 25. Separation of Concerns (SoC) Single Responsibility Principle (SRP)
- 28. http://technicbricks.blogspot.com/2009/06/tbs-techpoll-12-results-2009-1st.html Class, Struct, Enum etc.
- 29. Separation of Concerns (SoC) • “In computer science, separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. •A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. “ probably by Edsger W. Dijkstra in 1974 http://en.wikipedia.org/wiki/Separation_of_Concerns
- 30. Single Responsibility Principle (SRP) “Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.” by Robert C Martin http://www.ericalbrecht.com http://en.wikipedia.org/wiki/Single_responsibility_principle public class Logger : ILogger { public Logger(ILoggingSink loggingSink) {} public void Log(string message) {} }
- 31. Read, Read, Read
- 32. Clean Code Developer – 2nd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/
- 33. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 3rd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 35. “.. information hiding is the principle of segregation of the design decisions on a computer program that are most likely to change, ..” Information Hiding Principle (IHP) by David Parnas (1972) http://en.wikipedia.org/wiki/Information_hiding
- 36. Interfaces / Contracts public interface ILogger { void Log(string message); } • Decouple Usage and Implementation through introduction of a contract • Allows to replace implementation without changing the consumer public class Logger : ILogger { public Logger(ILoggingSink loggingSink) {} public void Log(string message) {} }
- 38. “Liskov’s notion of a behavioral subtype defines a notion of substitutability for mutable objects” Liskov Substitution Principle (LSP) by Barbara Liskov, Jannette Wing (1994) http://en.wikipedia.org/wiki/Liskov_substitution_principle http://www.objectmentor.com/resources/articles/lsp.pdf
- 40. Dependency Inversion Principle (DIP) • “High-level modules should not depend on low-level modules. Both should depend on abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions.” http://en.wikipedia.org/wiki/Dependency_inversion_principle http://www.objectmentor.com/resources/articles/dip.pdf by Robert C. Martin
- 41. Next Silicon Valley Code Camp Oct. 2016 https://www.siliconvalley-codecamp.com
- 42. Mini Conferences – User Groups
- 43. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 3rd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 44. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 4th Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 46. An implementation is open for extension but closed for modification Open/Closed Principle (OCP) by Bertrand Meyer (1988) http://en.wikipedia.org/wiki/Open/closed_principle
- 48. “ • Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. • Each unit should only talk to its friends; don’t talk to strangers • Only talk to your immediate friends.” Law of Demeter (LoD) Northeastern University (1987) http://en.wikipedia.org/wiki/Law_Of_Demeter
- 49. Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle S O L I D Robert C Martin: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- 50. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 4th Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 51. Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/ Clean Code Developer – 5th Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.de
- 52. Clean Code Developer Graphic by Michael Hönnig http://michael.hoennig.de/2009/08/08/clean-code-developer-ccd/
- 53. Summary Clean Code Maintainability is achieved through: • Readability (Coding Guidelines) • Simplification and Specialization (KISS, SoC, SRP, OCP, ) • Decoupling (LSP, DIP, IHP, Contracts, LoD, CoP, IoC or SOA) • Avoiding Code Bloat (DRY, YAGNI) • Quality through Testability (all of them!)
- 54. Downloads, Feedback & Comments: Q & A Graphic by Nathan Sawaya courtesy of brickartist.com theo@designitright.net www.designitright.net http://speakerrate.com/ speakers /18667-theo-jungeblut
- 55. Time to say Thank You! The Organizers Evergreen Valley College (team) The volunteers (how about you?) TheSponsors Picturesfromhttp://blog.siliconvalley-codecamp.com
- 57. … more References Resharper http://www.jetbrains.com/resharper/ FxCop / Code Analysis http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx http://blogs.msdn.com/b/codeanalysis/ http://www.binarycoder.net/fxcop/index.html Code Contracts http://msdn.microsoft.com/en-us/devlabs/dd491992 http://research.microsoft.com/en-us/projects/contracts/ StyleCop http://stylecop.codeplex.com/ Ghostdoc http://submain.com/products/ghostdoc.aspx Spellchecker http://visualstudiogallery.msdn.microsoft.com/ 7c8341f1-ebac-40c8-92c2-476db8d523ce// Lego (trademarked in capitals as LEGO)
- 59. … thanks for you attention! And visit and support the www.siliconvalley-codecamp.com Please fill out the feedback, and… www.speakerrate.com/theoj
Editor's Notes
- A object or any type implementing subtype or a certain interface can be replaced with another object implementing the same base type or interface.