Why do we rewrite software? SumUp. A better way to get paid 1 2 - PowerPoint PPT Presentation

Why do we rewrite software? SumUp. A better way to get paid

1 2 Why do we usually Inexperience It’s fun rewrite code? 3 4 Better solution Technical available Debt SumUp. A better way to get paid

Code that negatively Old libraries? and repeatedly affects the Code I didn’t write? speed or quality of delivery Technical debt Code I wrote before I knew Features that no one uses what I was doing? SumUp. A better way to get paid

Technical debt 😱 Speed of adding new features Time SumUp. A better way to get paid

Recurring technical debt 😱 Speed *refactor* of adding new features Time SumUp. A better way to get paid

Second system effect The tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems due to inflated expectations and overconfidence. “The Mythical Man Month: Essays on Software Engineering” - Frederick P. Brooks Jr. SumUp. A better way to get paid

“Legacy code” often di fg ers from its suggested “ alternative by actually working and scaling . ” - Bjarne Stroustrup, Inventor of C++ SumUp. A better way to get paid

Is this my destiny? e t i r w e R https://www.vectorstock.com/royalty-free-vector/ouroboros-snake-eating-its-own-tail-eternity-or-vector-12076546 SumUp. A better way to get paid

HARD FACT The real cost of software is not the initial development, but maintenance over time SumUp. A better way to get paid

THE QUESTION IS NOT Why do we rewrite software? SumUp. A better way to get paid

How can we make our systems more resilient to inevitable change ? SumUp. A better way to get paid

😱 Speed of adding new features Time SumUp. A better way to get paid

🙄 Speed of adding new features Time SumUp. A better way to get paid

How do we reach this nirvana? “Good architecture” 🙅 SumUp. A better way to get paid

Feels detached from daily Hard to spell problems No clear definition What does a software Sounds elite architect even do? “Architecture” has become a dirty word SumUp. A better way to get paid

Architecture as enabling constraints Constraints about how we use data and code that help us move faster over time SumUp. A better way to get paid

Enabling constraints in real life 🚙 SumUp. A better way to get paid

Enabling constraints in Programming paradigms Paradigm Constraint & Enablement From function pointers to classes → OOP Independently deployable subcomponents Functional From mutable to immutable data → Eliminate race conditions and concurrency problems SumUp. A better way to get paid

Enabling constraints in Frontend development Paradigm Constraint & Enablement var → const No more reassignment → Predictable data jQuery → React No more DOM manipulation → Predictable UI CSS → CSS-in-JS No more naming / side-effects → Safety and fewer global clashes SumUp. A better way to get paid

We are constraining ourselves all the time SumUp. A better way to get paid

We trade constraints for safety and speed SumUp. A better way to get paid

N O T E X H A U S T I V E 3 constraints you can use today for more resilient frontend architecture SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Constraint Enables SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Constraint must point inward Enables SumUp. A better way to get paid

A few ways of organizing our dependencies Layered Big Ball of Mud Modular SumUp. A better way to get paid

What’s the difference? Constraint Big Ball of Mud Layered Source code dependencies must point inwards SumUp. A better way to get paid

Constraint Big Ball of Mud Layered Source code dependencies must point inwards *changed* SumUp. A better way to get paid

Huge or unknown regression scope Cross-team conflicts Constraint Big Ball of Mud Layered Source code dependencies must point inwards *changed* SumUp. A better way to get paid

Constraint Ball of Mud Layered Source code dependencies must point inwards *changed* *changed* SumUp. A better way to get paid

Limited regression scope (Usually) does not affect other teams Constraint Ball of Mud Layered Source code dependencies must point inwards *changed* *changed* SumUp. A better way to get paid

Key difference between a ball of mud and a well-organized monolith is dependency organization SumUp. A better way to get paid

Constraint Source code dependencies must point inwards SumUp. A better way to get paid

Constraint Source code dependencies must point inwards Router API / Data For each page, UI Layer the rest of the application does not even exist Business logic Page 1 Page 2 SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Constraint must point inward Easier to isolate Enables impact of changes SumUp. A better way to get paid

What about shared components ? Design system 🎩 -or- copy-paste ✂ SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Be conservative Constraint must point inward about code reuse Easier to isolate Enables impact of changes SumUp. A better way to get paid

WE ♥ DRY SumUp. A better way to get paid

The result is often brittle and side-effect ridden code in the name of code reuse SumUp. A better way to get paid

Impact of time on shared code SumUp. A better way to get paid

Impact of time on shared code if , context, branches… SumUp. A better way to get paid

DECOUPLED > DRY Code reuse is not a goal in and of itself SumUp. A better way to get paid

Sometimes you just need two glasses! SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Be conservative Constraint must point inward about code reuse Easier to isolate Avoid coupling Enables impact of changes code that diverges over time SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Be conservative Enforce your Constraint must point inward about code reuse boundaries Easier to isolate Avoid coupling Enables impact of changes code that diverges over time SumUp. A better way to get paid

Router Page Other Page Business logic Subcomponent import Business logic SumUp. A better way to get paid

Router Page Other Page Business logic Subcomponent import Business logic ✂ SumUp. A better way to get paid

Router Page Other Page Business logic Subcomponent Business logic SumUp. A better way to get paid

Router Page Other Page Business logic Subcomponent Business logic SumUp. A better way to get paid

Forbidden dependency tests BUILD FAILING SumUp. A better way to get paid

Forbidden dependency tests .dependency-cruiser.json { "forbidden": [{ "name": "Your Page", "comment": "Should not depend on other pages", "severity": "error", "from": { "pathNot": "^pages/YourPage" }, "to": { "path": "^pages/YourPage" } }] } npm install --save-dev dependency-cruiser SumUp. A better way to get paid

Constraints for more resilient frontend architecture 3 1 2 Source code dependencies Be conservative Enforce your Constraint must point inward about code reuse boundaries Easier to isolate Avoid coupling Preserve your Enables impact of changes code that diverges architecture over time over time SumUp. A better way to get paid

The real cost of software is maintenance over time, because change is inevitable 👀 💱 What we’ve learned 🚙 We can make small changes to Architecture is about make our projects more applying enabling constraints resilient (1. Think directionally , to how we use code and data 2. Be conservative on reuse, 3. Enforce our boundaries) SumUp. A better way to get paid

👀 Every time you write a function (or don’t), create a new module (or don’t), you’re making an architecture decision SumUp. A better way to get paid

🚙 You don’t have to derive architecture from first principles SumUp. A better way to get paid

👌 Thank you! @monicalent