Author: Calvin Ng
At Celayix, we are working with a React frontend. An advantage of working with React is component composition, or using existing generic components to compose a more specific one. This gives us an opportunity to create components that are not tied to one project and can be freely shared amongst many different and unrelated ones.
The problem with this is that there will be some confusion as to the ownership of these components. To make the most of your common components, they should be shared organization-wide, but once you start adding more teams to the mix is where this confusion begins. Who is responsible for components that don’t belong to a specific team or project? Let’s take a look at some potential solutions:
1) One person will manage common repositories
This person becomes the dedicated maintainer of common repositories for your entire organization. It will be this person’s responsibility to review all pull requests to ensure they meet the organization’s guidelines for reusability and backwards compatibility.
2) Several people manage common repositories
These people become the maintainers of the common repositories for their respective teams. It is their responsibility to review the pull requests within their teams to ensure they meet the guidelines.
3) Everyone manages common repositories
Nobody is specifically tasked with maintaining common repositories; instead, each developer is responsible for knowing the organization’s guidelines.
Which is the best option? It depends. Having fewer people manage common repositories will ensure better adherence to standards and translates into higher quality and safer components, but having dedicated maintainers means less people working on features. Having more people manage common repositories results in the inverse scenario; code will be churned out faster but code quality may take a hit.
As with many things related to project management, it is a matter of manpower and how much of it you currently possess. At a larger company where adherence to established standards is often paramount, you may want some dedicated maintainers. At a smaller company you will not have the luxury of manpower but enjoy an ease of communication perhaps allowing you to forego dedicated maintainers. In any case, we believe working with common components is the way to go, the hard part is finding an organizational structure that will work for you.