Android Legacy. Part 1
Part One: Assessing the Magnitude of the Disaster
This is mostly a “managerial” section. Look at what subsystems and related components you have and in which part of the business logic there are more bugs. Make a color markup, highlighting bugs with red color. Make a list of “dangerous” integrations; it’s a case where the UI poorly processes the actions of a network subsystem, or the user logout is not smooth enough – UI + Data management.
Cut into layers, a classical architecture
Perhaps, it is not worth writing about, but I should mention it. As usual, look at UI, Controller/Presenter, Data Model and where possible start extending them to separate classes. No need to do everything at once; start from moving the UI into separate custom views, and network and data handling into another part. It’s easy to write test for that, and it will give you actual outcomes.
Moving to complex space and encirclement
Sometimes you need to carefully add a new feature; try to add it according to the rules of pure architecture or some other pattern. This will allow you to show your colleagues all the benefits and convenience of an architectural approach other than a legacy one.
Add new features using abstraction layers
I want to focus your attention on that. Once you add a new feature, use additional abstraction layers. First, it means accurate refactoring during the feature implementation, which the management will surely buy. Second, it’s good for future refactoring and optimization of neighboring components. Plus it means simplified code, and therefore a possibility to cover the code with tests. And that is very important in projects with a large code base.
Check out the second part of our article on Android Legacy where we continue our template of usefull steps that you need to do.