Monorepos and Separation of Concerns: 3 Key Insights for Teamwork and Future Scalability in Robotics
As a robotics tech startup, it can be tempting to adopt a monorepo approach to manage the codebase of projects. A monorepo is a single code repository that contains all of the code and dependencies for a given project or organization. This approach can be easier to maintain than a microservices approach, where different systems and components are spread across multiple repositories.
However, even though a monorepo can be easier to maintain, it is still essential to maintain a separation of concerns between the different components for maintainability, teamwork, and to prepare for the possibility of splitting the repository in the future.
Navigating the Codebase
Maintaining separation of concerns within a monorepo helps to keep the codebase organized and easy to understand. For example, if all of the code for a robot’s movement control, sensing, and autonomy are separated into different directories within the monorepo, it will be easier for developers to navigate the codebase and understand the various components of the robot. This is especially important for larger projects, where getting lost in a sea of code can be easy.
Regarding teamwork, maintaining a separation of concerns within a monorepo can ensure that different teams work on other parts of the robot without interfering. For example, suppose the sensor data processing and decision-making teams are working on different directories within the monorepo. In that case, they can be confident that their code changes won’t affect each other, especially if interfaces are well-defined. This can minimize conflicts and ensure the development process runs smoothly.
Another critical aspect to consider is that even though a monorepo might be convenient now, in the future, the business needs or the complexity of the robot may change. It might make sense to split the repo into multiple repos. A clear separation of concerns within the monorepo will make it easier to separate the codebase into smaller repos if necessary.
In conclusion, as a robotics tech startup, even though a monorepo can be easier to maintain compared to a microservices approach, it is still essential to maintain a separation of concerns between the different components of our robots for maintainability, teamwork, and the potential of splitting the repository in the future. Keeping the codebase organized and easy to understand allows teams to work together more efficiently. It will be easier to separate the repo if it becomes necessary.