The Status Refactor

What is refactoring?

Developers can probably skip this section.

Sometimes when you’re working on a project, things get thrown together in a fast, but somehow not-optimal way. It works, but it’s not pretty. Or maybe it is even pretty, but if you look close it’s REALLY not pretty. A similar thing happens in programming, where pressures of delivering on time, at all, or to a certain specification may lead to choices and solutions which are faster to implement now, but are harder to work with in the future. And it also usually leads to a bunch of developer grumbling about “spaghetti code”, “tech debt”, and sometimes even “bus factor”. If the developers are lucky enough, they will still be alive when a refactoring effort is made: spending time to go through old, messy code, and clean it up.

Why refactor Status?

When we started putting together Status, we made a bunch of choices like this. You can read about some of them in our post about StatusQ. We were still figuring out the direction of Status, and what features we wanted in the application. We ended up writing most of the backend code in Nim, which was new to a lot of us.

This all made the application core somewhat… vague at first. The application continued development, and as more and more features were added, plans made, code written, the developer grumbling reached a crescendo… and a refactor was ordered. We realized it was unsustainable long term to continue without solidifying our foundation. So to speak.

Some of the goals of the refactoring effort are:

to use SOLID principles in our code
to rewrite the backend in C++ instead of Nim (which is awesome! But didn’t exactly match our needs; specific issues were the lack of multiple inheritance and concept nesting only supporting two levels)
to improve our automated testing framework
to use Cmake for better compatibility with more development tools
to improve the stability of our vendor library
to document and standardize status-lib because it supports multiple teams
to upgrade the frontend to Qt6
to better encapsulate UI logic in stores

We planned for the refactor to take approximately a month, but even at that time were imagining this might be a bit optimistic.

We began October 1^st. Currently the refactor is still underway, but we’ve gotten a lot of big stuff done so far, including the UI store refactoring. Some big things we’re still working on are the C++ rewrite, the transition to Cmake, and the move to Qt6.

Stores

For a bit more explanation of our UI and Qt, check out our (previously mentioned) last article about StatusQ! stores are non-visual Qt objects representing a collection of properties and functions that interact with the backend. This isolation of responsibility makes it easier for the frontend and backend to develop and collaborate.

So you have a half finished refactor…

We have completely finished parts of an extremely ambitious refactor! And our developers already attest that the code is much easier to work with—particularly with the drive to adhere to SOLID principles—and that the refactoring effort has made our developers better, given them extended vision into multilayered architecture, and taught them many new things. And keeping things simpler means less frustration, confusion, and effort required to make future changes to the codebase. If you'd like to see more details about the refactoring effort, you can check out some of the work done here.

It’s good to deal with tech debt.