In the world of prototyping, you try to build a minimum viable product (MVP) as quick as possible in order to present something for the business-section of a company. Often, the MVP is expanded with multiple new features. This turns it into a full enterprise-sized application that needs to stay maintainable over a long period of time.
When you don’t take enough measures at the start of your prototyping cyclus, the increase in scope of a prototyping project could hurt you. In the long run, the code could get dirty and unreadable, depending on how fast you need to deliver. In this blog, we give 5 tips to improve code quality while prototyping.
When prototyping, it’s important that you start the project with a fully configured linter in order to write code in a uniform way across multiple developers. A linter with a good configuration that works for the team might take a long time to set up, but it will be worth it.
The linter makes sure that code is formatted correctly, making code readable for everyone who has to look at it. Enabling or disabling a certain set of rules might also prevent logical errors that occur in your code. When an error goes against a rule that has been set up, you will know immediately.
A great example of a linter that is used by many big companies is the linter of Airbnb. Especially for JavaScript projects, this one is strongly advised.
In a team project, a very good feature to use when delivering code is working with pull requests to bring new code into the existing codebase. Using PR's has a few advantages. First, bad code gets spotted on the fly. Secondly, everyone can read the code. This makes pull requests a great way to share knowledge between team members.
In our software projects, pull requests are heavily used. There are a set of rules applied to pull requests that made us able to improve not only the quality of our code but also streamline the delivery of new features in our development process.
The workflow that we use is as follows:
In the past, we released new versions of our applications by packaging the source, dragging it over via SFTP onto a server and finally restarting the process manually from a shell with various commands.
At the start, this was fine, as we could just do everything quickly and get on with it. However, when you are developing features on the fly and bugs occur, manual deployments are very inefficient. Manual deployment takes time and, more importantly, is prone to errors. You need to enter the commands manually and we, as humans, make typos. We fixed this problem by writing small scripts that do all the deployments for us.
Nowadays, we only need to push code to our git repository and the code automatically gets released on the chosen server. This makes it possible to deploy anywhere, at any time, without manual intervention. More importantly, this makes our deployment error rates drop.
Writing software that works is one thing. Making sure that everything continues to work when you develop new features is, however, another thing.
As we have developed prototypes that turned into fully operational enterprise-scaled applications, we saw a fair share of bugs getting introduced when the scope of the project changes.
We tackled the occurrence of bugs by writing tests for our applications. These tests guarantee that the application’s features keep working when changes to the codebase are made. When developing a new feature for an application, it is mandatory to provide a backing test. At any time, this test will check that the developed feature continues to work as expected. A good example of a framework that helps you with testing your code is Cypress.
We use this tool to test our applications from a user’s viewpoint. This makes sure that all the possible actions they could perform work at any time. The set-up is extremely fast and easy to do and the entry level to write tests is very low, allowing you to rapidly write tests for the feature you are developing.
If you are building big enterprise projects or prototyping a short term project, you sometimes need to enter parts of code that you have never seen before. Sometimes, this makes it hard to see the complete picture. In addition, this could slow down your development process.
Writing our software by pair programming allowed us to deliver high quality software with barely any bugs. The lack of bugs arose because there were 2 people looking at the same piece of code. When one person would make an error in the code, the second person would spot it, causing a bug to be prevented before it might have even occurred.
Pair programming doesn't only lower the chance of bugs in code, it also makes sure that knowledge is spread around the team faster.
These five tips helped us develop prototypes more rapidly, while having less bugs. At Craftworkz, we are specialized in building a prototype in a matter of days. If you want to know more, make sure to visit our website. Moreover, if you want to know if your insane software idea is viable, we’ll help you do a sanity check. Just call our hotline and we will turn your dreams into reality 🔥
Written by
Want to know more?
