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...?
   

   View Slide

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
   

   View Slide

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
   

   View Slide

4. @fernando_cejas fernandocejas.com
   Are we going to talk
   about architecture
   and software
   design?
   

   View Slide

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.
   

   View Slide

6. Clean Architecture
   

   View Slide

7. Ports and Adapters
   

   View Slide

8. Everything Architecture
   

   View Slide

9. and the list continues...
   Onion Layers
   Monolithic Architecture
   Model View Controller
   Microservices
   Modular Monolith
   Event Driven Architecture
   Unidirectional Architecture
   Microkernel Architecture
   Nanoservices
   

   View Slide

10. Which architecture to we pick?
    What makes a good one?
    That makes us thing and wonder...
    @fernando_cejas
    fernandocejas.com
    

    View Slide

11. It depends...
    

    View Slide

12. pick and architecture
    and stick to it!!!
    It does not matter actually...
    

    View Slide

13. The most IMPORTANT is the
    ecosystem around your architecture.
    

    View Slide

14. Organization
    PROCESSES
    TEAM STRUCTURE
    Consistency
    GOOD
    PRACTICES
    EVOLUTION
    Simplicity
    PHILOSOPHICAL
    PRINCIPLES
    PATTERNS
    (and anti-patterns)
    but wait...
    Which ecosystem???
    

    View Slide

15. Philosophical
    Principles
    ...let's not be confused with S.O.L.I.D...or any other
    Software Principles...
    

    View Slide

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...
    

    View Slide

17. Design Patterns
    ...and anti-patterns...
    

    View Slide

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
    

    View Slide

19. Good Practices
    

    View Slide

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.
    

    View Slide

21. Please: No code committed
    WITHOUT Tests!!!
    

    View Slide

22. Processes
    

    View Slide

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.
    

    View Slide

24. Team Structure
    

    View Slide

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.
    

    View Slide

26. Architecture
    evolution
    

    View Slide

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
    

    View Slide

28. Extra Ball
    

    View Slide

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.
    

    View Slide

30. Finishing up:
    Architecture is not only
    about code.
    There should be an
    ecosystem and a set of
    tools around it.
    No silver bullets.
    

    View Slide

31. if a codebase is
    hard to work with...
    then change it!!!
    @fernando_cejas
    fernandocejas.com
    

    View Slide

32. THANK YOU!!!
    @fernando_cejas
    fernandocejas.com
    

    View Slide