How to Refactor your


Software Architecture

Your Host Today

@pinchito
@influencity

We Will See


A Fork in the Road


How to Improve a Running System


Live Migrations


Practical Case: Influencity


Conclusions

A Fork in the Road

Congrats!


You are the new CTO of ACME, Inc.


You have to deliver results


Our old system is too slow, limited, crappy


We need the new system for last week


Start working now!

The Old System

First Way


Work within the confines of the system


Build more stages on an unstable architecture


Work slows down on a crawl


"Rowing in chewing gum"

Second Way


Throw everything away



Stop new requirements for two years


Why will the second time be better?

Second System Effect


- Fred Brooks, The Mythical Man-Month, 1975

Practical Case: Mortgage Workflow


Two million euros


25 people working for two years


New requirements were being implemented

in the old system


Catch-up was impossible

Mortgage Database


Database with ~100 tables


Renormalized to third normal form


Result: 400+ tables


Never saw production (thankfully!)

A Third Way?

How to Improve

A Running System

Repay your Technical Debt


Debt allowed you to build things faster


Debts must be payed at some point


Use part of the team to repay debt

Software Development is Awesome!


The only business where you can renovate a house...


While living in it!


And not be uncomfortable

Build a Good Test System


Or three


Unit tests are great but expendable


Test backend code


Test APIs


Test frontend code

Refactor!


Make small, incremental changes


Intersperse with business improvements


Improve as you go along


Always leave the code better than it was

Lose the Fear to Make Changes


This code was here before I joined

This code must be here for some reason

This code must be awful because reasons

Simplify!


Graph your current architecture


Reduce the number of moving parts


Remove gears that do not run smoothly

Move Slowly But Surely


Business needs its pound of flesh


Involve the whole team


Don't be afraid of manual work

Simplify!


Graph your current architecture


Reduce the number of moving parts


Remove gears that do not run smoothly


No need to understand old code perfectly!

Tools Are Great


But so easy to misuse


Don't be afraid to build if necessary


The most experienced devs should do infra


... But all the team should be involved

Live Migrations

The Fluid Architecture


Allows you to make changes


Make incremental changes


Allow you to move seamlessly to the next state


Article (in Spanish)


Backend Changes


Always add services


Never modify services


Never delete (while in use)

Frontend Changes


Atomic changes


Forward compatible


Must be reversible if necessary

Database Migrations


Better without a fixed schema


Even better if avoided


Make everything backward compatible


Migration strategies (in Spanish)

Practical Case:

Influencity

Initial Status


Deployments every three months


"Stop the world" deployments


Painful data migrations

Influencity Architecture

Influencity Database

Stupid Integration Tool


multi-deployment-server

Three Test Systems


Backend: test controllers


Frontend: test to end tests


Manual tests

7 Months Later


Deployments every other week


Rebuilt about half the platform


Improved every aspect

Final Target


Continuous Deployment


5 ~ 10 deployments per day


Full frontend tests

Conclusions


Your team is your strength


Preserve backward compatibility


Migrate reversibly



Thanks!

@pinchito