12.
Common Legacy App Problems
Written by Lance Gleason
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Heads up... You’re accessing parts of this content for free, with some sections shown as text.
Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.
Unlock now
In an ideal world, your team will write a new Android app that will use TDD development techniques from the beginning. In this world, your app will have great test coverage, an architecture that is set up for TDD, and code with a high level of quality. Because of that, the team will be very confident in its ability to fearlessly refactor the code, and they will ship code regularly.
In the real world, many, if not most, apps have technical debt that you will need to work around. In this chapter, you will learn about some of the more common issues you will run into with legacy applications. Then, in subsequent chapters, you will learn how to address these when working on legacy projects.
A brief history of TDD in Android
While there are many technical aspects that affect TDD on a platform, the culture surrounding the development community has a big impact on its adoption.
Android was first released on the G1 in 2008. In those days, the primary development language was Java and, as a result, many early developers came from other Java domains, such as server-side development. At that point, TDD as we know it today had only been around for nine years and was just beginning to see adoption in some software development communities and organizations. During that time, the Rails framework, which was four years old, arguably had the largest percentage of projects being developed using TDD. This was due, in part, because many signatories of the Agile Manifesto were evangelizing it.
Java was 12 years old at that time and pre-dated TDD. It had become a mature technology that large conservative enterprises were using to run mission-critical software. As a result, most Java developers, with the exception of those who were working at cutting edge Agile development shops, were not practicing TDD.
This enterprise Java development culture affected the early days of Android development. Unlike Rails, the initial versions of Android supported testing as more of an afterthought, or not at all. As a result, most new Android developers had not come from an environment where testing was important or even known; it was not a primary concern of the framework and most developers focused on learning how to write apps, not on testing. During those early days, many of the concepts we take for granted today were just beginning to be developed. Over time the platform evolved, devices became more powerful, and apps became more complex.
Eventually, tools like Robolectric and Espresso were introduced and refined. TDD became more of an accepted practice among Android developers. But even today, it is not uncommon to be at an Android developer meetup where fewer than half of the developers in the audience are actively writing tests or practicing TDD on a daily basis.
Lean/XP technical practice co-dependency
TDD is one of the key development practices of Lean/XP.
Lean/XP fun historical facts
In software, the techniques we use were built on the shoulders of the giants, often from other industries. TDD/XP has roots in manufacturing through a subset of Six Sigma techniques, which are called Lean. To learn more about Lean, XP and its relationships, this Wikipedia article on Lean software development is a great place to start: https://en.wikipedia.org/wiki/Lean_software_development.
No unit or integration tests
This is the biggest issue you will likely run into when working on a legacy project. It happens for a variety of reasons. The project may be several years old and the development team may have chosen not to write unit tests. For example, it is not uncommon to find teams with technically strong Android developers who do not know how to write tests. Of course, if you are on a team that does not know how to practice TDD, this book would make a great gift, especially for holidays, birthdays or “just because.” :]
Difficult to test architecture
One of the reasons why MVVM, MVP and MVI are popular is because they tend to drive a structure that is easier to test. But, if the app was initially developed without any unit tests, it is likely there is no coherent architecture. While you may get lucky with a design that is testable, it is more common to find an untested app with an architecture that is, in fact, difficult to test.
Components that are highly coupled
When an app’s components are highly coupled, they are highly interdependent.
class Cat(
val queenName: String,
val felineFood: String,
val scratchesFurniture: Boolean,
val isLitterTrained: Boolean)
class Dog(
val bestFriendName: String,
val food: String,
val isHouseTrained: Boolean,
val barks: Boolean)
fun findPetsWithSameName(petToFind: Any): List<Any> {
lateinit var petName: String
if (petToFind is Cat){
petName = petToFind.queenName
} else if (petToFind is Dog) {
petName = petToFind.food
}
return yourDatabaseOrWebservice.findByName(petName)
}
@Test
fun `find pets by cats name`() {
val catNamedGarfield = Cat("Garfield", "Lasagne", false, false)
assertEquals(2, findPetsWithSameName(catNamedGarfield).size)
}
@Test
fun `find pets by dogs name`() {
val dogNamedStay = Dog("Stay", "Blue Buffalo", false, false)
assertEquals(5, findPetsWithSameName(dogNamedStay).size)
}
@Test
fun `find pets by lions name`() {
val lionNamedButterCup = Lion("Buttercup", "Steak", false, false)
assertEquals(2, findPetsWithSameName(lionNamedButterCup).size)
}
open class Pet(var name: String, var food: String)
class Cat(
name: String,
food: String,
var scratchesFurniture: Boolean,
var isLitterTrained: Boolean): Pet(name, food)
class Dog(
name: String,
food: String,
var isHouseTrained: Boolean,
var barks: Boolean): Pet(name, food)
fun findPetsWithSameName(petToFind: Pet): List<Pet> {
return yourDatabaseOrWebservice.findByName(petToFind.name)
}
@Test
fun `find pets by cats name`() {
val catNamedGarfield = Cat("Garfield", "Lazagne", false, false)
assertEquals(2, findPetsWithSameName(catNamedGarfield).size)
}
Components with low cohesion
One important tenant for Object-Oriented Design is to have components that focus on doing one thing well. This is also referred to as cohesion. For example, let’s say you have a class called Car:
class Car {
val starter = Starter()
val ignition = Ignition()
val throttle = Throttle()
val engineTemperature = Temperature()
var engineRPM = 0
var oilPressure = 0
var steeringAngle = 0L
var leftDoorStatus = "closed"
var rightDoorStatus = "closed"
fun startCar() {
ignition.position = "on"
starter.crank()
engineRPM = 1000
oilPressure = 10
engineTemperature = 60
}
fun startDriving() {
if(leftDoorStatus.equals("closed") &&
rightDoorStatus.equals("closed")) {
steeringAngle = 0L
setThrottle(5)
}
}
private fun setThrottle(newPosition: Int) {
if (ignition.position.equals("on") && engineRPM > 0 &&
oilPressure > 0) {
throttle.position = newPosition
engineRPM = newPosition * 1000
oilPressure = newPosition * 10
}
}
}
class Engine {
val starter = Starter()
val ignition = Ignition()
val throttle = Throttle()
val engineTemperature = Temperature()
var engineRPM = 0
var oilPressure = 0
fun startEngine() {
ignition.position = "on"
starter.crank()
engineRPM = 1000
oilPressure = 10
}
fun isEngineRunning(): Boolean {
return ignition.position.equals("on") && engineRPM > 0 &&
oilPressure > 0
}
fun setThrottle(newPosition: Int) {
if (isEngineRunning()) {
throttle.position = newPosition
}
}
}
class Car {
val engine = Engine()
var steeringAngle = 0L
var leftDoorStatus = "closed"
var rightDoorStatus = "closed"
fun startCar() {
engine.startEngine()
}
fun startDriving() {
if (leftDoorStatus.equals("closed") &&
rightDoorStatus.equals("closed")) {
steeringAngle = 0L
engine.setThrottle(5)
}
}
}
Other legacy issues
A large codebase with many moving parts
Many legacy systems, over time, become large apps that do a lot of things. They may have hundreds of different classes, several dependencies, and may have had different developers — with different development philosophies — working on the project. Unless you were the original developer on the project, there will be sections of the app code that you don’t fully understand. If you are new to the project, you may be trying to figure out how everything works.
Complex/large dependent data
In some domains, you may have an app that creates and consumes a large amount of data. Those projects may have a large number of models with several unique data fields. Taming this beast as you test can easily look like a insurmountable task, so stay tuned for tricks on how to address this.
Libraries/components that are difficult to test
A lot of libraries and components have very important functionality that is easy to use, but did not consider automated unit tests as part of the design. One example is using Google Maps in a project with custom map markers. If you had to create this functionality, you would have to write a lot of code. But, integration tests can be very challenging. In some instances, the best solution may be not to test these components because the value added by the tests are lower than the effort to create tests.
Old libraries
This happens a lot: A developer needs to add functionality to an app. Instead of reinventing the wheel, they use a library from the Internet. Time passes and the library version included with the app is not updated. If you are lucky, the library is still being supported and there are no breaking changes when you update it.
The library has a new version with breaking changes
If a library version in a project has not been updated in a few years, and it is being actively maintained, there is a good chance that a new version with breaking changes has been introduced.
The library is no longer being maintained
This happens for a variety of reasons, including:
Wrangling your project
The app is working well with no tests
After seeing all of the issues you can run into with a legacy project, you may be asking if you should start to add tests to the project. If you plan on continuing to maintain a project for a while, the short answer is yes, but with a few caveats.
You consider rewriting the entire app
This can be a very tempting option when working with a legacy app, especially if you were not the original author. If your app is small or truly a mess, that may be the best solution. But, if your project is large, and you are planning on keeping most of these features, however tempting a rewrite may be, it could be a job-killing move.
Key points
- Lean and Extreme Programming have a lot of interdependencies.
- Many legacy applications have little or no automated tests.
- Lack of automated tests can make it difficult to get started with TDD and may require getting started with end-to-end Espresso tests.
- Rewriting a legacy application should generally be considered as a last resort option.
Where to go from here?
Beyond the techniques you will be learning in this book, the book Working Effectively With Legacy Code by Michael Feathers does a great job of talking about legacy code problems. You can check out this book at https://www.oreilly.com/library/view/working-effectively-with/0131177052/.