15 Tips to Building Quality Software | by Mark Miller

Manual developer tests, isolate temporary code, and more

Mark Miller
Gears — photo from wonderopolis.org

This 5-letter acronym outlines general software design principles that help make your code robust. Read more about it here and here.

When working on a large feature, take adequate time needed to think through how to architect the feature effectively. Think about how all the components will communicate.

The two main ways to organize code are package by layer and package by feature. With package by layer, you essentially place classes in the architectural layer that they belong to. For example, you might put all your custom view classes in one package, all your repository classes in another package, all your model classes in another package, etc.

For example, if you create a custom view for feature A it’s generally best if you do not reuse that custom view for feature B even if it needs a similar (or the same) view.

  1. Break off the feature and create a new custom view with the modified requirements.

Take the time upfront to think through all edge cases as you work through features. You should have an understanding of what can go wrong with each part of the code that you work on.

Live Templates are a feature in Android Studio/IntelliJ IDEA that allows you to quickly insert boilerplate code. This is an incredibly powerful feature that can increase your productivity (as well as reduce copy/paste bugs).

Generally, developers work on tickets created by product managers. The ticket would have the details for a given feature that you’re working on (along with the acceptance criteria).

No matter how important the feature is, it’s important to take one step at a time and think everything through. Even if you’re “behind” don’t let it get to you. If you’re trying to run as fast as you can, chances are you’ll leave some bugs behind or miss an edge case that could have been prevented.

Say you want to quickly start a new activity you’re working on to test it out or maybe you want to simulate some kind of temporary condition in code.

The integration points are one example of a potential blocker. Suppose you’re working on a new client side feature that requires API integration. Assume that it will take one day to complete the API and 5 days to complete the client side work. It’s a good idea to test the API very early on in the process (like as soon as it’s ready) even if you have not finished building the UI.

When you’re done building the feature you should try to break it. Do some of your own manual developer testing to make sure you didn’t miss any edge cases and things work as you’d expect. This will help shorten the feedback loop.

Ideally, every feature that you build should have unit tests. If the code is not testable then it needs to be improved so that it is testable.

Standard code reviews are another great way to catch errors and potential improvements. A thorough code review is much more valuable than simply clicking the approve button.

Keeping a close eye on crash reports right after a release can prove to be helpful. It’s a great feeling when you can identify and fix errors before they get too large.

Tagging the commits that you release will make your life easy if/when you need to roll back to a previous version. I use tags like release/1.2.3–456 that indicate the release number.

Leave a Comment