$30 off During Our Annual Pro Sale. View Details »

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

Fernando Cejas
September 29, 2022

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.

Fernando Cejas

September 29, 2022
Tweet

More Decks by Fernando Cejas

Other Decks in Technology

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