Many teams want to incrementally build a portfolio of reusable components so multiple projects can leverage them. This post will provide a list of potential areas to look for achieving systematic reuse – chances are that you have a few components in these areas already. Assembling them into a standard set and making it available for easy consumption will dramatically increase adoption rates across projects. Here are the areas to invest and/or harvest existing code:
- Configuration – specifically properties that vary across environments (e.g. DEV, QA, PROD). How are teams defining and managing this information today? If you are using Maven, teams may be employing multiple strategies – profiles, assemblies, custom scripts, naming conventions, etc. Why not consolidate practices?
- Transformation APIs – many projects require data transformation between objects to JSON or objects to XML and vice versa. Teams might be using different transformation libraries, may be wiring them with Spring or other dependency injection frameworks in a bespoke manner. Why not adopt a consistent API that provides transformations via a common set of classes with pluggable format-specific providers?
- Flexible Query Construction – lookup methods that require one or more parameters will end up having common boiler plate code that binds parameters using boolean conditions – why not provide a reusable API that allows the developer to wire parameters using a common API?
- Integration with internal and/or external systems – retrying, alerting, message construction, metrics, and proactive monitoring are all cross cutting concerns that are common across projects. Teams must be realizing these capabilities using multiple APIs, injection hooks, and response loops – again a consistent and reusable API will not only cut development costs but also make application support simpler
Existing code and components do however carry several risks that have to be addressed to realize reuse potential. For example:
- How domain agnostic are the components? Does it have a well defined interface and ability to adapt to a family of use cases?
- What is the learning curve for developer adoption? Does it have well defined adoption patterns that are easy to learn and intuitive?
- How testable is the component? Does it have interfaces that capture and model varying behavior ?
- What is the support model for the component? How to submit bug fix or enhancement requests? is there enough expertise in the developer community?
- What will be the release cycle for reusable components ? This becomes critical as more projects start to leverage a common suite of components for a varying set of capabilities
Tagged: API, refactoring, software investment, software reuse, systematic software reuse Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
