Dev Notes #7 – Inevitable Complexity
I was busy fixing some bugs yesterday. As I'm implementing a fix for an issue that someone reported, I came across some code that I supposedly wrote several months ago. The funny thing is, I have no memory of writing this code.
It's just a a reminder of just how big FoodNoms has gotten. The project is so big now that I can't even fit it all into my head anymore – even stuff I wrote relatively recently. How do I manage?
I have started treating the FoodNoms codebase as if a team is working on it. Even though I'm a one man team, it's now a multi-person codebase (or actually a suite of codebases). What does this mean in practice?
- Unit tests. I invested a lot in testing with FoodNoms 2, and so glad I did! A lot of nuanced behaviors are easiest to capture in a test, and it prevents me from making the same mistakes twice.
- A strong foundation. I've found it's so beneficial to invest a TON of time into the "core" of the app. The most reusable pieces. The foundational models. Don't worry so much about perfecting code "on the fringe", e.g. the UI and non-stateful components. This was the impetus for me starting FoodNoms 2 in the first place. The foundation of FoodNoms 1 was incredibly shaky and fragile, which made it super risky to add new features.
- Code comments. Actually write comments in the code – especially when I'm doing something not immediately obvious or if it's really important.
- Automated monitoring and alerting. I recently set up Datadog for some server components to alert me when a server is experiencing issues or if a cron job has stopped running unexpectedly. I sleep better at night knowing that I have these alerts set up!
- Lots of manual QA. It's unavoidable – you have to spend a lot of time manually QAing your work.
Perhaps none of these things are surprising, but I've learned just how important they are, even when you're working alone.
There's more I could probably do (one thing I want to explore some day is UI testing), but today this is good enough for me.