7 Proven Practices to Increase the Speed of Development and Quality of Projects

All of these points can be applied to mobile development, web frontend, and backend. I have gathered these practices through various teams and the issues I have faced over the past six years. When you create a project from scratch, these practices can be particularly helpful. Some of them can fit you perfectly, while others may not. If you have your perspective and different experiences, I would be glad if you share them here. By the way, if you are a mid-level or junior developer who wants to advance, applying these practices to your team can really help. Let's get started!

1-Mocking backend responses until ready

In a standard software development process, when a business requests a new feature, it is distributed among several teams: frontend, backend, and mobile app development.

Then, each team progresses with planning and task breakdowns. But what if the backend team needs more time to develop its part? What if they can only provide completion points once a week?

The backend becomes a bottleneck.

Mobile and frontend development teams work like this: “Oh, the backend has already implemented it…

2-Coordinate with the back-end team on endpoints and organizations for the conclusion.

2a. Implement a back-end API with stub responses. The Faker library can be helpful for generating sample data.

2b. Or apply stubs on the front end. This could be an object with data directly in the code. For example, in Node.js, you can skillfully implement it using dynamic imports and avoid increasing bundle size:

getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); };

This could also be a fake HTTP service that retrieves JSON files from assets instead of making actual requests.

Hide features behind feature flags.

Once the backend is ready, switch to the actual API and verify that everything works as expected if you have used the frontend stubs perspective, and enable this feature flag.

Feature Flag

Now, as you may have seen in the previous section, I mentioned feature flags. In short, a feature flag, also known as a feature toggle, allows developers to enable or disable features in a live environment. There are cases where they are useful: gradually rolling out new features, A/B testing, enabling beta features, and applying hotfixes.

We use GitLab to store feature flags. It is a dedicated repository used by both backend and frontend projects. The good news is that it has a user-friendly UI, allowing product managers to manage features themselves. Initially, we used to use separate feature flags for each project repository. However, this approach did not provide the ability to disable features for the entire product at once. Therefore, we bring everything into one repository.

3-In code, it looks quite simple:

In the project, we obtain all active feature flags. Under the hood, we use GitLab Unleash (a feature toggle service), and we use its official client.

Then, in the code, we simply use features.YOUR_FEATURE, which needs to be hidden.

You are in the feature flag…

4-Monitoring errors for tracking issues in a production environment.

When our product underwent production application from the MVP stage, we were concerned that users might encounter errors that we couldn't reproduce and may not even be aware of. After researching error-tracking tools, we settled on Sentry. The experience has been positive. Now, let's go through some important details.

Redundant Errors:

Under the hood, any unhandled exception will be tracked. As the number of applications and users grows, the number of errors can become so high that it's nearly impossible to notice anything genuinely significant. If you don't filter out unnecessary content, Sentry's inbox can turn into a landfill. For example, canceled requests, connection issues, and errors from connected scripts are entirely useless and will only clutter your work email with notifications. As a solution, you can add filters in the configuration. To achieve this, just define the before sending the callback and add it to your sentry Package. Unit. In this callback, you can analyze each captured error and discard it (return null) if it's unhelpful. Here's an example of such a filter…

4-Monitoring

The path of a trace ID

Imagine a situation where you successfully catch an error in the logs, but the information in the details is inadequate. You turn towards the logs, but how can you identify a specific error among thousands of requests and more log lines per second? How can you differentiate the right people, create a request chain, and indicate the precise error, especially when your business has multiple teams and is integrated with other services? This is where tracing comes in.

Tracing provides a complete outline of an invocation and identifies the exact method of failure, even when the message is communicated asynchronously by a message broker.

It allows you to easily determine on which side the error occurred when integrating with different teams.

Tracing is also useful for performance debugging. For example, it can help determine if rendering takes longer or if a method is not adequately optimized in a microservice.

In our specific implementation, we used Jaeger, which is based on the Open Tracing API.

In summary, each request and all its method calls are tagged with a unique label. Each label contains its parent and child relationship, the time it took, and the relevant metadata.

5-Performance optimization

When we applied MVP to the fintech app, we had a complex form. At that time, I was still young and inexperienced. Eventually, we realized that our project was becoming slow. We had to spend extra hours figuring out why. We had several unnecessary re-renders because we overlooked some fundamental rules related to props in React. I wanted to make every possible effort to avoid such situations in the future.

So, I added this kind of project linters and added an initial configuration to run Why-did-you-render on package.json. In summary, this plugin issues a warning if something is unnecessarily re-presented and suggests how to avoid it. Additionally, we also run the lighthouse in headless mode. Some people say that pre-optimization is bad, but for me, it's a principle: do it from the beginning.

6-Defined code styles for all team projects.

You may have heard of the principle of broken windows. If there is a broken window in a building and nobody fixes it, eventually there will be no windows left in the building.

The fewer rules and controls there are in a project, the more tempting it is to write low-quality code or write it in an entirely different style. Inappropriate code increases the time it takes to understand it, while clear, familiar, and concise code allows for quick reading. In our team, we have described the coding style in one place. As a great starting point, you can use Prettier or Airbnb code style.

7- Regression Testing

There has been a lot of literature written about various types of tests, perspectives, and how to write them correctly. One thing to note is that no product can survive without regression testing. Therefore, we focused on creating a comprehensive end-to-end testing framework, and based on that, we wrote tests that are related to BDD scenarios and user stories. We used the Page Object pattern to organize our code and the Playwright framework to interact with browsers. To test in different browsers, including Safari, you can use a solution called Moon, which can be hosted on any of your servers.

Thank you for taking the time to read this article! In conclusion, this article sheds light on the key software engineering practices that enhance development processes and code quality. By adopting techniques such as backend response mocking, feature flags, error monitoring, performance optimization, code style standards, regression testing, and tracing, you can build more skilled and trustworthy software. Let's continue to improve our software and stay in touch!