Almost as popular as the state management discussion is production-ready code.
The magical code that I’m always asked about. Especially on my YouTube tutorials, “Can you make a production-ready version of this”, to which I always reply, “This is literally the code directly from a production app”.
It’s good to know what it actually means to write production-ready code, that’s what this post will dive into.
There’s no “special production-ready code”, it’s the same as all the other code.
Let’s look at the 6 traits of a production-ready codebase:
- An implemented architecture
- Track Analytics and user usage
- Crash and stability reporting
- Your app is released to production
- Strict code review guidelines for new work
- Your speed of delivery increases over time
Having all these present in your codebase means you know how your app is being used, how stable it is, which features are the most used, and how your app is performing. Let’s dive into each one.
An implemented architecture
I don’t have an architecture that I recommend, only one that I use personally for clients.
I use MVVM simply because it’s the simplest architecture that I know of. The goal of choosing an architecture is to allow you to have an opinion in your code base. Where new files go, how responsibilities are shared, and how to grow the codebase.
In the beginning, not choosing an architecture is perfectly fine, but when in production it helps with guidance on further development.
Tracking Analytics and Usage
If you don’t know how your app is used by your users you don’t have production-ready code.
Your code might be in production, but it’s definitely not ready to be in production. This is an easy-to-implement step, that many overlook, but without it, you shouldn’t be in production. If you are then you should consider implementing analytics.
Add basic analytics, then move on to custom events based on your app use case.
Crash and Stability reporting
Similar to analytics tracking, you need to know the stability of your app, this is a requirement for code to be considered production-ready.
Without this, you cannot know:
- If there are any bugs in your software
- the users experience when using your app
- If there are issues stopping users from completing an important task
Basic crash reporting for uncaught exceptions is a good start. The best is having all exceptions, caught and uncaught, go to reporting. Caught exceptions should be non-fatal, and uncaught exceptions should be fatal.
This allows you to monitor internal code health, answering the question “Are all assumptions we’ve made in code true in the production world?”
The app is released into production
The idea is a bit counter-intuitive, that your app has to be in production to be considered production-ready.
The reason is, you cannot learn what you require to operate effectively in production without being in production. Once the app is released you’ll have the following questions:
- How are users using the app?
- How many users are using the app?
- Is my code throwing any exceptions?
- Is my code functioning as I expect it to?
- Which views do users spend the most time on?
- Are users experiencing any bugs in production?
- What are the most common use cases in the app?
Answering these questions is how I determined the traits outlined in this post.
Strict code review guidelines
Once your app is in production you have set a standard, whether it’s low or high, but it’s set.
You now need to adhere to that standard or raise it, consistently. To achieve this you can set strict requirements for your code reviews. Even if you’re a solo developer, holding yourself accountable with a simple checklist is useful. Here are our requirements:
- Does the new business logic have unit tests?
- Does you run
dart fixandflutter analyze? - Is our documentation updated with the changes you’ve made?
- Did you run all the tests before making a PR (unit and integration)?
The goal is to ensure you maintain a certain level of code-quality from this point forward.
Your speed of delivery increases over time
This one was a requirement for our projects. I would often allow developers to spend up to 3 weeks just on a refactor, while the rest of the team carries the feature development.
My goal is always long-term, and if yours is too then this should be important. You have to aim for the following:
- Old work is never retested manually
- Regression tests take less time as the app grows
- Integration issues should be caught during the development
- All critical use cases for a feature should be tested by a computer
Writing self-testing code is the answer, but it’s not easy to do. I’m working on a service to help teams take their first step toward long-term speed in 4 weeks or less. If you want to save time on manual testing and avoid long dev cycles reply to this email with a message that you’re interested and I’ll reach out.
If your app is already in production and you have none of these, don’t worry. Each of these is independent of the other so you can dedicate a few days a week to get them all ready.
I hope you enjoyed this post,
See you again next week.
