Clean Code / Clean Architecture

Transcript

1. Clean Code Clean Architecture Arkadius Jonczek 02.07.2024
2. Awareness.
3. We use High-Level Programming Languages…
4. … to write Code for Human Beings.
5. … a high-level programming language is a programming language with strong abstraction from the details of the computer. https://en.wikipedia.org/wiki/High-level_programming_language
6. Computers understand this: 0101 1100 1011 1001
7. Human Beings understand this: fmt.Println("Hallo Welt")
8. That‘s great. But that‘s not enough…
9. …because this is not a guarantee to write code that is easy to read and understand.
10. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler
11. Why is that important?
12. Hidden costs.
13. Hidden costs. https://www.planetgeek.ch/wp-content/uploads/2013/06/Clean-Code-V2.2.pdf
14. And frustrated Developers as well.
15. The Solution: Clean Code
16. Clean Code is code that's easy to read, maintain, understand and change through structure and consistency yet remains robust and secure to withstand performance demands. https://www.sonarsource.com/solutions/clean-code/
17. Code is clean if it can be understood easily – by everyone on the team. With understandability comes readability, changeability, extensibility and maintainability. All the things needed to keep a project going over a long time without accumulating up a large amount of technical debt. https://www.planetgeek.ch/wp-content/uploads/2013/06/Clean-Code-V2.2.pdf
18. So how do we get our code clean?
19. Clean Code https://www.generic.de/blog/clean-code-development-grade
20. Don‘t repeat yourself (DRY)
21. Keep it simple and stupid (KISS)
22. Boy Scout Rule
23. Tell don‘t ask
24. Law of demeter
25. You ain‘t gonna need it (YAGNI)
26. SOLID
27. SOLID https://blog.stackademic.com/solid-principles-explained-with-real-time-examples-e39d1c167ba5
28. Single Responsibility Principle • V1: A module should have one, and only one, reason to change. • V2: A module should be responsible to one, and only one, user or stakeholder. • V3: A module should be responsible to one, and only one, actor. • Vx: Gather together the things that change for the same reasons. Separate things that change for different reasons. https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
29. Open Closed Principle • V1: A software artifact should be open for extension but closed for modification. • Vx: A Module should be open for extension but closed for modification. https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
30. Liskov Substituion Principle • V1: What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. • Vx: A program that uses an interface must not be confused by an implementation of that interface. https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
31. Interface Segregation Principle • Vx: Keep interfaces small so that users don’t end up depending on things they don’t need. https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
32. Dependency Inversion Principle • Vx: Depend in the direction of abstraction. High level modules should not depend upon low level details. https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
33. Wow. Clean Code is great.
34. But sometimes life is not that perfect and we have to deliver results.
35. Make it work, Make it right, Make it fast. Kent Beck
36. But what about the Architecture?
37. Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
38. The End is near.
39. https://productcoalition.com/a-comprehensive-guide-to-the-software-development-life-cycle-sdlc-15b7892e1d44
40. The End.
41. Thank you.