Technical debt is a concept in software development that reflect the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

- wikipedia

Debt is paid back with interest

When you take a shortcut, you use your credit card

Communicate technical debt to your project managers. 

Action #1

... Only then can they make an informed decision if they should use their "credit card"

Me Before Knowit

What is the problem with competitive programmers?

If you only measure speed then you incentivize writing ugly code without documentation. Be sure to measure the right things!”

Measure the right things

Action #2

... be mindful of what you measure,
you just might get it

Why am I talking about measurements when they clearly aren't the responsability of you as a developer?

Dev. vs Ops.

What happens when you have one team doing dev. and one team doing ops?

Introspection

source: https://procrastination.com/blog/31/objectivity-dunning-kruger-effect

Which changes can be made to processes or the organization to mitigate the mess that inexperienced developers make?

Have a proper onboarding to the organization and project

Action #3

Hint: It's not about having the smartest people

Psychological safety

The best way to boost performance is to create an environment where everyone can contribute and reach their potential

Facilitate cooperation

Action #4

... both with managers and other devs

https://www.reddit.com/r/cableporn/comments/7molue/the_spaghetti_monster_got_a_makeover/

You're constantly paying interest on your technical debt, and the debt creates more debt

Filtering

What happens when you can filter from many places?

MapScreen

filtering logic & data

Drawer

Layout of drawer

Fields

Navigation

Map

Hovering top filter

Referral flow

Stores
Store data

Dedicated data store for filters

Components can set & get data from here

Components can observe the store

..and rerender when the data changes

Observer-pattern

Also known as publish-subscribe

Pattern #1

Instead of passing data around, store it a dedicated location and let components that need the data subscribe to changes.

This can easily be done in react with mobx
(or redux, or written yourself with listeners, or ...)

How should you pass functionality around?

Abstract reusable logic into controllers

Pattern #2

... the same way we put data into stores instead of sending it through many layers of components

Stores
Store data

Filter data
e.g. "minRating"

Fetching providers

Non-functional requirements

• Error logging
• Authentication

Issue: doing this properly is a lot of code

Please don't put network logic in your views

Abstract it into a network layer.

Let the network layer handle authentication
and error logging

Make authentication reusable

Make good error logging easy

Consistent error logging is extremely nice for debugging

Abstract network layer
from your views. 

Pattern #3

... make error logging and authentication easy, otherwise you can't debug production issues

Benefit of abstractions

Loosely coupled abstractions allow mocking & developers can work in parallel on different modules

What do you do with the data from your API?

The providers originate from different online provider/booking API's which present data on different formats.

Text

What if you can't handle the format differences backend?

Create a coordinate model &
factory that transforms between formats

Coordinate model

Factory for transforming between formats

In better languages the solution is overloaded constructors

Create a model for your data.

If needed create a factory to transforms between formats

Pattern #4

Add models for complex data

Map data from services to your model

Tying it together

• Stores allow you to have data sentralised and available in different parts of your application
• Observer- or publish-subscribe pattern can be used to update views when stores change.
• Controllers allow you to reuse logic across components and extract unnecessary boilerplate from views
• Services should fetch data
• Models keep your data easy to use
  • Factories transform raw data to models

MVC in frontend?

Originally implemented by Trygve Reenskaug in the 1970's for smalltalk