Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

A sweet taste of clean code and software design

374 vues

Publié le

Introduction to clean code and software design, definitions and approaches

Publié dans : Ingénierie
  • Soyez le premier à commenter

A sweet taste of clean code and software design

  1. 1. A Sweet Taste of Clean Code & Software Design Kfir Bloch, Developer linkedin/in/blochkfir github.com/kfiron@kfirondevkfirb@wix.com http://kfiron.com
  2. 2. Hi. I am Kfir. coding, open source software, cooking HOBBIES Lithuania Ukraine Vilnius Kyiv Dnipro Wix Engineering Locations Israel Tel-Aviv Be’er Sheva
  3. 3. As software engineers, we try to...
  4. 4. As software engineers, we try to... Develop / deliver fast Have a software which is easier to change
  5. 5. Clean Code and Software Design Can help us do it.
  6. 6. Clean Code in a Nutshell
  7. 7. Software code that is formatted in a modularized and systematic manner so that another coder can easily interpret or modify it. Wikipedia Clean Code
  8. 8. Clean Code “You can call it beautiful code when the code also makes it look like the language was made for the problem.” Ward Cunningham
  9. 9. Clean Code “Clean code always looks like it was written by someone who cares.” Michael feathers “You can call it beautiful code when the code also makes it look like the language was made for the problem.” Ward Cunningham
  10. 10. Clean Code “Clean code always looks like it was written by someone who cares.” Michael feathers “Clean code is about recognizing that your audience isn't just a computer, it's real- live humans!” Cory House “You can call it beautiful code when the code also makes it look like the language was made for the problem.” Ward Cunningham
  11. 11. Clean Code should be like your car’s dashboard. A sneak preview gives you all the information you need.
  12. 12. Solving a problem fast isn’t enough.
  13. 13. Solving a problem fast isn’t enough. Organizing things for yourself isn’t enough.
  14. 14. Solving a problem fast isn’t enough. Organizing things for yourself isn’t enough. Others need to make sense of it too.
  15. 15. Indentations, White spaces, Tabs Naming! reveals intent Small functions Length of lines Number of arguments When to break lines Structured packages and folders DRY – don’t repeat yourself Declarative and expressive And more… Clean Code Characteristics
  16. 16. Indentations, White spaces, Tabs Naming! reveals intent Small functions Length of lines Number of arguments When to break lines Structured packages and folders DRY – don’t repeat yourself Declarative and expressive And more… Clean Code Characteristics It’s all about paying attention to the details.
  17. 17. Can you tell what this function does? def send(userId: String, to : String, cc : String, body: String) ={ if(cc != null && !cc.contains("@") && !cc.contains(".")){ Failure(new InvalidEmailException("invalid email")) } else { if(to != null && !to.contains("@") && !to.contains(".")) Failure(new InvalidEmailException("invalid email")) else{ bi.logEmailSent(userId, System.currentTimeMillis()) Success(mail.sendEmail(userId, to, cc, body) ) } } }
  18. 18. def sendEmail(emailMessage: EmailMessage): Try[Id] = Try { validateEmail(emailMessage.to) validateEmail(emailMessage.cc) bi.logEmailSent(emailMessage.userId, System.currentTimeMillis()) mail.sendEmail(emailMessage) } def validateEmail(email: String): Unit = if (email != null && !email.contains("@") && !email.contains(".")) { throw new InvalidEmailException(s"the email: [$email] is invalid") }
  19. 19. // OK "Dog service" should { "add dog" in { dogHouse.addDog(defaultDog.copy(age = 25)) must beSuccessfulTry dogHouse.dogsByAge(20, 30) must contain(defaultDog.copy(age = 25)) } } // Excellent "Dog house" should { "Add dog with age 25 and returns with dogByAgeInMonths()" in { val dog = defaultDog.withAgeInMonths(25) dogHouse.addDog(dog) must beDogAdded dogHouse.dogsByAgeInMonths(from = 20, to = 30) must haveDog(dog) } }
  20. 20. As your software grows, it becomes less readable. It’s all about paying attention to the details.
  21. 21. Design in a Nutshell
  22. 22. Make code easier to change Find where to change Know fast what to change Fast reaction to pain, hiding pains Do not bypass layers, avoid leaky abstractions Focus about ‘why’ and not ‘how’ Our goals in design
  23. 23. Software Design Abstraction Refinement Modularity Data Structure Software Procedure Information Hiding Software Architecture Control Hierarchy Structure Partitioning
  24. 24. Four rules of simple design: 1. Tests Pass 2. Expresses intent 3. No duplication (DRY) 4. Small Kent Beck
  25. 25. Domain Driven Design (DDD) - Domain focus, Domain expert - Bounded contexts - Building blocks (Entities, Repositories, Domain event, services) Eric Evans
  26. 26. Approaches for design lifecycles Big Design Up-Front Waterfall Well defined process Architects culture UML
  27. 27. Big Design Up-Front Long process Documents becomes stale In any case software is changed and will be changed Narrows the world of a developer Waterfall Well defined process Architects culture UML Approaches for design lifecycles
  28. 28. TDD – Beginner’s mind Code from the first day and make changes along the way Don’t care about architecture or platforms/cloud envs Approaches for design lifecycles Evolutionary Design
  29. 29. Persistent might be completely different Domain might change dramatically We expose API which is wrong but need to be supported We don’t think about our consumers Moving to be eventual consistent might break everything Approaches for design lifecycles Evolutionary Design TDD – Beginner’s mind Code from the first day and make changes along the way Don’t care about architecture or platforms/cloud envs
  30. 30. If we pay attention to design principles we’ll be able to change everything. But we can do better.
  31. 31. Obviously, there is large spectrum between the 2 approaches. Evolutionary Design Big Design Up-Front
  32. 32. Evolutionary Design Big Design Up-Front There’s no one coherent solution. We’re engineers! Like doctors, we need to look for a good fit.
  33. 33. Tools for determining where your project is on the spectrum
  34. 34. #1 | Size Matters
  35. 35. #1 | Size Matters Big project: We need some up-front design Smaller project: Beginner’s mind might work
  36. 36. #2 | Lifecycle Matters Kent Beck
  37. 37. #2 | Lifecycle Matters Beginner’s mind Should be done with design, and we gain info already
  38. 38. #3 | Consumers Matter Are we exposing internal APIs? Are we exposing external APIs? Are we producing / consuming events from queue? It is always a good idea to design the domain and API with your consumers
  39. 39. Walking skeleton is great, but not enough. You need to actually develop the obvious on the first day – Sunny day with minimum. #4 | Fill in the obvious Filling in the obvious gets you into the domain, feel the pain and address it. There are more unknown pains that you be able to discover only when start coding
  40. 40. #5 | YAGNI is no excuse to deliver bad design Sometimes, taking the time to think in advance about design details is a good thing. You’re an engineer, you get paid to think.
  41. 41. #5 | YAGNI is no excuse to deliver bad design Sometimes, taking the time to think in advance about design details is a good thing. You’re an engineer, you get paid to think. #6 | TDD is not Test-Driven Design It’s not enough that your tests pass. Your software can still suck. TDD is a tool that gives you confidence in design.
  42. 42. Clean Code Design Takeaways You wake up in the morning to deliver, sustainable delivery.
  43. 43. Clean Code Design Takeaways You wake up in the morning to deliver, sustainable delivery. Even though you code for the machine, it needs to be read as a story for humans.
  44. 44. Clean Code Design Takeaways You wake up in the morning to deliver, sustainable delivery. Even though you code for the machine, it needs to be read as a story for humans. Find the balance between up-front design and evolutionary design.
  45. 45. Clean Code Design Takeaways You wake up in the morning to deliver, sustainable delivery. Even though you code for the machine, it needs to be read as a story for humans. Find the balance between up-front design and evolutionary design. You get paid to make hard and ??? decisions.
  46. 46. Thank You linkedin/in/blochkfir github.com/kfiron@kfirondevkfirb@wix.com http://kfiron.com

×