Brewing better code... What makes a good architecture?

Many times when we think about architecture in terms of software design, we found ourselves thinking only about code, but that is not ideal, since in real life what makes a good and scalable architecture is the ecosystem around it, acting as a good companion fostering code maintenance, scalability and evolution of the project.

In this talk we are going to see who are the key players when it comes to a good software design/architecture.

Transcript

1. Presented by @fernando_cejas Brewing better code... What makes a better architecture...? Is it ONLY about code...?
2. A story of coffee, programming and architecture. About presenter and presentation... Coffee and Programming relationship: As programmers, we turn coffee into code... Presented by @fernando_cejas I'm Fernando Cejas: Head of Engineering @Tignum Continuous learner FOSS Advocate
3. Did you know? 52% Beethoven was a coffee lover who wanted his coffee prepared in a particular way. He demands that each cup of coffee he drinks must be precisely 60 beans. The person who discovered coffee was an Ethiopian goat herder named Kaldi. He once noticed how his goats become sleepless and restless after eating berries from a certain plant. In Europe, a whopping 52% of coffee consumed outside the home is drunk in the office or at work. @fernando_cejas fernandocejas.com
4. @fernando_cejas fernandocejas.com Are we going to talk about architecture and software design?
5. How do we define architecture? Software architecture is, simply, the organization of a system. This organization includes all components, how they interact with each other, the environment in which they operate, and the principles used to design the software. Software architecture is designed with a specific mission or missions in mind.
6. Clean Architecture
7. Ports and Adapters
8. Everything Architecture
9. and the list continues... Onion Layers Monolithic Architecture Model View Controller Microservices Modular Monolith Event Driven Architecture Unidirectional Architecture Microkernel Architecture Nanoservices
10. Which architecture to we pick? What makes a good one? That makes us thing and wonder... @fernando_cejas fernandocejas.com
11. It depends...
12. pick and architecture and stick to it!!! It does not matter actually...
13. The most IMPORTANT is the ecosystem around your architecture.
14. Organization PROCESSES TEAM STRUCTURE Consistency GOOD PRACTICES EVOLUTION Simplicity PHILOSOPHICAL PRINCIPLES PATTERNS (and anti-patterns) but wait... Which ecosystem???
15. Philosophical Principles ...let's not be confused with S.O.L.I.D...or any other Software Principles...
16. You are not Gonna Need It It states we should not not add functionality until deemed necessary. Keep it Simple Stupid It suggests not to increase the complexity of things and fully focus on what really matters. Divide and Conquer It means grabbing the problem and splitting it up into smaller ones, thus simplifying the solving approach. Do not reinvent the wheel The wheel already exists, and does the job quite well. Nobody needs to “reinvent” it, they just use it in different ways. Philosophical Principles...
17. Design Patterns ...and anti-patterns...
18. Design Patterns They solve problems A patterns is a proven solution to a recurring problem. They can become anti-patterns Singleton (OOP) Lava anti-pattern (OOP) They are common language If we say "Factory" or "Builder", everyone can fully understand what we are talking about. Examples (OOP) Decorator Facade Observer @fernando_cejas
19. Good Practices
20. Good Practices Consistency Code should be consistent and uniform (structure should look familiar in the codebase). Sanity Check Be defensive in order to avoid production errors and mistakes. Architecture Fitness Establish rules and restrictions to fulfill the architecture requirements. Reusability Avoid code duplication and reuse across projects.
21. Please: No code committed WITHOUT Tests!!!
22. Processes
23. Processes Pair Programming Four eyes see more than two. Engineering Collectives Foster collaboration and technical discussions. Automate All Things Continuous Integration and Delivery for the win. Code Style. Pull Requests Aim to have small ones (no more than 400 lines of code) in order to facilitate reviews. around code writing that help organization and consistency Code Reviews A couple of approvals unless done via pairing. Pair reviews.
24. Team Structure
25. Conway's Law in a nutshell From Wikipedia: Conway’s law is an adage stating that organizations design systems that mirror their own communication structure.
26. Architecture evolution
27. Zero Bugs Technique to erradicate as many bugs as possible. Behavioral Analysis Detect behavior in your codebase. New Technologies Bet on new technologies when possible. Code Metrics Cyclomatic complexity, static analysis, etc Tech Debt Detection Tech Debt Radar meetings. Architecture Evolution
28. Extra Ball
29. Object Oriented Programming. Functional or Reactive Programming. Framework or Libraries. The technology being used could potentially dictate the rules (or impose some restrictions) in our architecture.
30. Finishing up: Architecture is not only about code. There should be an ecosystem and a set of tools around it. No silver bullets.
31. if a codebase is hard to work with... then change it!!! @fernando_cejas fernandocejas.com
32. THANK YOU!!! @fernando_cejas fernandocejas.com