Aurajoki Overflow: Codebase Management - Sponsored by Knowit

Welcome to the Aurajoki Overflow February meetup!

The February meetup is sponsored and made possible by Knowit.

In this month's meetup we will be discussing Codebase Management. We will be discussing adapting to change, refactoring and how to keep yourself sane while handling larger projects and growing demands.

Registration opens on this page on Monday 30.01.

Schedule:

18:00 Doors Open / Welcome! Bewerages and snacks!
18:10 Introduction to the meetup and a word from our sponsor Knowit
18:15 Juho Härme: Refactoring with stratified design
19:00 Break with refreshments, snacks and food
19:15 Petter Holmström: Growth Pain - A Developer's Story
20:00 Hanging out, Lightning Talks, Relaxing
22:00 -> Afterbeers @ SKAAL

Talks:

Juho Härme: Refactoring with stratified design

Looking at a code base one often gets the feeling that it should "have better design", be split into more reasonable chunks or have more clarity. However, conducting a refactoring based on a mere feeling is tricky and suggesting PR fixes without good arguments and helpful ideas on what to change and why might be unfruitful and frustrating.

Stratified design is a term used e.g by Eric Normand (2021) to describe a functional approach in which code is looked at as layers. Each function / piece of code should belong to a specific layer - stratum - based on how it relates to other code and what goal it has.
In my client work I have found stratified design to be a valuable tool in both refactoring and building new as it provides a guideline for making actual low-level design decisions. This presentation demonstrates the use of this pattern with two koa based nodejs api endpoints as examples (from an actual project, anonymized for the presentation). I will show how a new api endpoint was added with stratified design in mind and compare the decisions made to an unrefactored endpoint.

Petter Holmström: Growth Pain - A Developer's Story

Once upon a time, there was a project. It started out quite small but with a tight schedule. Decisions were made, corners were cut. Then the world changed and the little project saw an opportunity to adapt and to become something more than it had ever been. More decisions were made, the architecture was changed. The project grew. One repository became 20. More balls had to be kept in the air at the same time. Something more had to change. This is a true story about scaling and growing, but with an emphasis on the development process and team structure, and daring to explore.