Reusing code and repaying technical debt
We have a few first generation apps on in the wild that still waiting to be reviewed with regards re-usable code and repaying their technical debt.
Recently I learned about the concept of technical debt, which could be any code that has not yet been viewed for isolation, refactoring and testing.
Not wanting to leave these few projects in this state I need to revisit them with a view to refactoring components into isolated packages that have had their functionality quality assured by unit and integration testing.
This will also have an added benefit of providing our business with new packages (wheels that don't have to be reinvented) and reduced costs to our customers.
I'll want to start looking into the Pear library packaging system to define start point for my process. I also will be re-reading Stuart Herbert's interesting blog post series called Beyond frameworks for guidance.
I'm hoping to discover how I can develop packages that will provide APIs to object instances but also view partials or even aggregate solutions that include Javascript, CSS, forms etc. I'm not sure whether to implement these using iframes or other methods.
It will definitely be a learning process but it has the very attractive gain of shorter delivery times for software that use these components and quality assurance for our code. The package could also have a longer life span if you define and include dependencies with it.