In Redvike we always strive to deliver unique mobile apps which provide modern design and amazing user experience. This is usually the main target of our clients who want to persuade people to become paying customers, but that’s only a small part of our work. After reading this short post you will understand how we protect and maintain codebases so it’s extremely easy and fast to add new features in future releases or edit the old ones.
Project initialization with TypeScript
Prettier & Eslint
These two tools in combination with TypeScript are truly bug killers. Prettier is responsible for providing consistent code style. It formats our code automatically each time we save the file so it’s a lot easier to read the code. On the other side eslint delivers possibility to setup our own security rules and it is also used by a big companies like for example AirBnB. There are a lot of professional eslint plugins on the market, but we are using a few best one. Some of them are typescript-eslint, eslint-plugin-react and eslint-config-airbnb. With this setup we are always sure that our code is wrote along with the best quality.
React Native Testing Library
We hope everyone know the importance of writing tests during development, this is one of the main parts of our job. Well tested app codebase means no defects in future releases. It prevents from breaking functionalities while adding new ones or editing code. This is the least wanted thing for app owners to add new feature, unexpectedly break something else and push it to the production. To handle this problem we should always spend some time on writing tests. In Redvike we are using React Native Testing Library which provides fast and straightforward way to write unit and integration tests. In addition we test each feature in the way end users will use it.
Husky & Lint Staged
These tools give us a way to run own defined scripts before committing or pushing code to the app repository. This basically means we avoid committing broke code by developers by running pre-commit and pre-push scripts. They check if there is any error received from typescript, eslint or tests, if so, developer is unable to commit and have to fix the code first. Husky is responsible for invoking scripts immediately after git commit or push command, then lint-staged checks which files was added or edited, so we can avoid wasting time on linting untouched files.
Not enough? No worries that’s not all! Even if all checks from previous steps passed and code went to the repository there is one last step – code review. Each attempt to add or edit code must be reviewed by other developers. They scan code line by line to check one more time if everything is coded along with best practises. On this stage we comment the code and request changes if necessary to be 100% sure that codebase is fine.
To sum up
We hope we clarified well our process of code maintenance. So now, it will be easier for everyone to understand how we take care of apps not just from the visual side. There are a lot of ways to handle this problem but we found our approach good enough. It helps us to minimize bug chances every single day!