Managing big teams is no easy feat. Everybody has their own preferences, working style, and characters, and yet all those aspects need to come together to create a team of people dedicated to creating values for clients.
Below, we present 4 tools to streamline React Native app development in big teams.
The editor set up is something that developers love to personalize as much as possible. While seemingly there is nothing there to customize, there are things that used to (even) break projects before the era of modern editors. Line breaks, tabs vs spaces (while not that important in JavaScript, it’s a central topic in other languages).
Luckily, even though that’s the case, there are projects such as EditorConfig, and others, to help teams stay on the same page.
If the company does not provide a paid IDE and every developer has the freedom to choose his own, then some rules need to be applied for the outcome to be same in all cases. For example, some of the most common IDEs are VS Code (VS Code) and WebStorm (WS) for front end developers. Although for basic use cases those IDEs can provide the same functionalities, there are some specific scenarios they don’t. For example, in some if your team uses GraphQL in WebStorm there is a plugin to resolve the autocompletion based on the schema but in VS Code you’ll need to download and install a plugin to have the same output. This is a small example that the team will need to set some common rules to have the same output despite the IDE that the developer uses.
VS Code is slowly becoming the standard text editor for all TypeScript developers. Its main pros are the fact that Microsoft’s text editor is offered for free, and that it’s easily extensible by countless plugins. That is a great benefit, although also a con. Each added functionality is added start-up time, and more
WebStorm is a variation on the popular IntelliJ IDEA editor – the standard among Java, and Kotlin developers. It provides support for multiple frameworks and libraries out of the box. The level of support is top-notch, and the integrations are of superb quality.
Most of the plugins JavaScript developers rely on are first-party. This in turn means, that should any new tool emerge, that takes the hearts of developers by storm, WS users must wait a little for a plugin to be made available for them.
Fleet is JetBrains’s answer to VS Code. It runs in the browser, on PCs, it supports multiple languages out of the box, and it runs a similar AI engine as WebStorm or IntelliJ. It’s very early in development yet, so it does not do too well. We are sure that with time it might emerge as a worthy successor to all current-generation IDEs of the company
Another big problem is not following predefined rules for your codebase. From naming convention to functional component structures, spacing etc. Here is where ESLint comes in handy, solving some of those problems.
The set-up process itself is not difficult. All developers must have the linter installed and active to auto format the code. In some cases, though, setting up the rules can be quite complicated. For example, you can set a rule for imports and exports clustering on the top libraries imports and after those with a newline all the native files imports. This is tricky to set up and not always it will display the way you want.
This is where the developer himself needs to apply those rules and be sure that the outcome is the same as in other files. The process is crucial because it helps the review process of open PRs. If all the codebases follow the same rules, imagine how easy it will be for a developer to review the PR just by seeing a familiar structure, instead of reviewing a totally new file structure. The eyes are fast to adapt and spend less time understanding the code. The team should agree to the rules and apply them to the codebase.
It’s good to at least set the naming convention for interfaces, how you export files (via index.js or index.ts), usage of arrow functions, inline styles vs a Stylesheet object etc. All those rules take some time to define, however it's all more than worth it in the end.
Developing new features is one of the most exciting things for a developer and fun to do, but to avoid low quality code, they need to follow the rules of the architecture. When the time pressure is high, it is easy to just write whatever code they wish that works and move on to the new task. That does not mean that the job is done, though. It is important to understand the code base and follow the file structure rules.
When it comes to big projects, in most cases there are some common components, or some files dedicated to constants or interfaces. You need to globally and understand if the interface or the component will be reusable, or if the scope is specific to one screen, only. Based on those evaluations, you need to make the decision and place your work in the right place for future developers to have an easy time using it and understanding it.
Commonly, one creates a component specifically for one screen but after some time reusing it for another screen, or even worse: exporting the interface to use it in a totally different component. This can lead to complicated logic and playing Sherlock Holmes examining files to make sense of what is going on in the files.
To see an opinionated, scalable setup designed for enterprise apps, see our GitHub repository.
After the creation of the new feature, it’s time to open the PR. Here is one of the most important tasks for the developer. For you to create a new feature or fix the bug means that you spend a lot of time to understand the problem and to solve it. The reviewer faces the issue without knowledge on any of the parts of the issue. That’s why we must make their life easier. For starters, The PR must be linked to the story/task that was created for everybody to have easy access to all parts of the solution.
It’s a good practice to have a screenshot of the feature when finished or before and after images if it’s a bug. It’s hard for a developer to understand the outcome of the code on the screen, even for the most experienced one. A small description of what we developed or debugged is also important; this way you are explaining why you have done what you did. Now that the reviewer has a clear image of what they are reviewing, it’s time to dive into the code. If we followed the previous rules, the review should be straightforward and quite easy.
Finally, sharing knowledge is hard to do, considering the strict schedules and time pressure. Therefore, every project should contain all this knowledge in a database or a tool of sorts. A tool for that would be Notion, or some similar tool. It needs to be highly available, and optimally in the cloud. This way, the documentation will always be available for everyone. We won’t need to remember everything by heart, and the newcomers will have an easier way to adapt to the new environment. It’s always nice to have a buddy to guide you, although having everything you need to know written down in one place is a must. After all, humans developed writing for a reason. To store knowledge for the future reference. Let’s not leave this prehistoric invention to waste.
Developing apps in big teams can be a nightmare. It does not have to be this way, though. With the right set up, and the right tools, much of the cumbersome work can be done automatically for you. In our post, we have presented only a few examples of the rules of thumb when it comes to scalable React Native app development. Do you know any others? Share them with us!
.svg){kind=small}
