This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Or how to define the boundaries of an independent Bit component in your distributed codebase
The question of what should be an independent component, or how we should define the boundaries of a component, comes up quite often when developers start using Bit to implement a component-based architecture.
In case you happened to overlook Bit, Bit is a tool that helps developers build component-based applications and collaborate on components independent of a git repo or any other development setup.
To answer this post’s question, we must understand the purpose of a component-based architecture and component-driven development.
As you’ll see, the reasons for choosing this approach are the criteria for defining the boundaries of a component.
Maintainability
A maintainable codebase is one that can be easily understood, modified, and extended by developers over time.
There are several factors that contribute to making a codebase maintainable. We’ll focus on two of them.
Readability
Bit components are small decoupled units of code, that are easy to understand and reason about.
A component has an ID that is meaningful and descriptive. A component’s relation to other components, dependencies, and dependents is clear and explicit.
Changes to a component are isolated and easy to review. Furthermore, since Bit generates a clear dependency graph, the effects of a change are easy to predict.
To enjoy these benefits to the fullest, it’s important to keep components small and focused.
A component should generally be a small group of files with a single responsibility. It should not include more than a few hundred lines of code, at most.
The component should “do what it says on the tin” and not do anything else.
For example, the ‘netlify-deployer’ component, which is used to deploy app components to Netlify, should only handle the deployment and not generate the deployment artifacts.
Having descriptive naming conventions, and a clear separation of concerns, is essential to get the most out of this approach.
They allow you to inspect dependencies and dependents and understand the relationship between components without reading the code.
This translates to a faster and more efficient development process.
Reusability
Reusing existing code and existing components can reduce complexity and improve maintainability by leveraging tested and proven solutions.
Imagine a world where buildings and bridges fail (collapse) as often as the software does. This, fortunately, does not happen.
The reason is that physical structures are designed and built once, using proven and tested solutions. They are not modified and extended on the fly, as software is.
We cannot and should not stop modifying and improving our software systems, but we can learn from how physical structures are designed and built.
The more you reuse components, the more you use “proven solutions”, the more stable and maintainable your codebase will be.
A reusable component is one that can be used in multiple contexts by different components or applications. It should be extensible and configurable to allow for different use cases.
It should also abide by the Single Responsibility Principle and not include any code irrelevant to its purpose.
On the other hand, a component should not be “too focused” that it can only be used with another specific component.
For example, a UI ‘table-row’ component used to render a single row in a table will not be used by itself but rather as part of a ‘table’ component.
To reduce your codebase complexity and development time, a ‘table’ component should be able to render a single row, multiple rows, or even a single row with a header.
Note: In contrast to regular monolithic projects, components in component-based software, are not only used as “libraries”, but make up the entire application, from the very elementary and generic building blocks, to the most complex and concrete components, the apps.
That means, “reusability” should never be the only criterion for defining the boundaries of a component.
Independent delivery / Team autonomy
The component-based architecture allows individual developers and teams to author, maintain and deliver components independently.
This is a very important aspect of component-driven development and is one of the main reasons for using Bit.
To enable that, a component’s source code, excluding its dependencies, should be authored and maintained by a single team (and, correspondingly, a single Bit scope).
For example, a ‘sign-up-form’ component, hosted on the organization’s, should probably not include in its source files the implementation for the ‘terms-and-conditions’ section.
Instead, this section should be maintained as an independent component, by the ‘legal’ team/scope of the organization, and consumed as a dependency by the team/scope that maintains the ‘sign-up-form’ component.
Find out more:
Bit - Component driven development
Conclusion
In conclusion, adopting a component-based architecture and utilizing Bit can significantly improve your development process's maintainability, reusability, and team autonomy. By keeping components small and focused, adhering to the Single Responsibility Principle, and enabling independent delivery, you can optimize your codebase for both readability and reusability.
This approach encourages collaboration, reduces complexity, and ultimately results in a more efficient development process. Embracing component-driven development will help your team create stable, maintainable, and extensible software systems that can be easily understood, modified, and extended over time.
Mastering Component-Driven Development: Improving Maintainability and Collaborative Efficiency was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Eden Ella
Eden Ella | Sciencx (2023-03-29T15:19:38+00:00) Mastering Component-Driven Development: Improving Maintainability and Collaborative Efficiency. Retrieved from https://www.scien.cx/2023/03/29/mastering-component-driven-development-improving-maintainability-and-collaborative-efficiency/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.