Slide 1

Slide 1 text

Presented by @fernando_cejas Brewing better code... What makes a better architecture...? Is it ONLY about code...?

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

Clean Architecture

Slide 7

Slide 7 text

Ports and Adapters

Slide 8

Slide 8 text

Everything Architecture

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

It depends...

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

The most IMPORTANT is the ecosystem around your architecture.

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Good Practices

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

Please: No code committed WITHOUT Tests!!!

Slide 22

Slide 22 text

Processes

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

Team Structure

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

Architecture evolution

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Extra Ball

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

THANK YOU!!! @fernando_cejas fernandocejas.com