Legacy Code strategies


#1

Hallo World,
this is a kind of question I have always asked to myself and that would have been closed as too broad on other forums. So will be longer than the average, the next ones will be shorter.

John Smith is starting to work as a Senior Galactic Developer in Acme Company. He have to solve a ticket, let’s say to change a small ViewModel logic so to make something with a retrofit response.

But…
John Smith realizes that Acme colleagues knowledge of architecture is related only on how their houses are built, and that they do not have wise uncles that taught them what should be clean code. They are paid a lot and have to solve an issue, and making a small refactor, would have the same effect to throw a glass of water in the ocean.

A really common situation.
What John have to do to understand which line of code he should go from the screen he sees in the emulator to the ViewModel line he needs to intervene?

  1. He runs the Layout Editor? But from there he cannot see the single binding with the @id of the layouts, he only see a hierarchy of nested components, not where in the code are called.
  2. He runs the application putting some breakpoints, or Log.d with some common sense/consulting I Ching?
  3. He runs a Junit Test trying to do some refactoring?
    4 )He registers an Espresso call of that activity so that can understand what is going on?
  4. He executes control click(Ctrl/Command+B) everywhere to try to find the flow of the complex Application going from the Manifest, to the first OnCreate method in Application , trying to find his way through his quest to the holy graal viewModel?
  5. He uses some intelliJ plugin as CodeIris that gives him a clear view of the hundreads of classes, so that he can see graphically which class calls what
  6. He starts to change the name of every method
  7. He begin from scratch to do some TDD of the new feature, ignoring all the code?
  8. He hires an hypnotist to convince his colleagues that they need to refactor all the code.
  9. Something else? What is the best way to be time efficient in solving an issue when speaking to improve the code is not an option? Of course depends, but there is some way to act that is more time efficient/impactful than others?

#2

I cannot really answer that in the abstract. It would depend a lot on the nature of the app. Also, it is not like I do that sort of thing on a regular basis.

He runs the Layout Editor ? But from there he cannot see the single binding with the @id of the layouts

If the layout is using data binding, you now have the attributes to search for on a @BindingAdapter. If the layout is not using data binding, you now have the widget ID to try to track down (e.g., where findViewById() is used, where the Kotlin synthetic accessor is used).

He runs the application putting some breakpoints, or Log.d

I wind up doing a lot of this.

He runs a Junit Test trying to do some refactoring?

If these exist, they might help. Personally I tend to find them too artificial to learn the basics of what some chunk of code is supposed to do, though they are invaluable for making sure that I do not break anything when editing that code.

(most of the rest of your numbered choices I have not tried)

What is the best way to be time efficient in solving an issue when speaking to improve the code is not an option?

Talk to somebody who has already worked on the code base. For example, if the project is under Git control, you can see who last edited the code in question (right-click in the gutter in the Android Studio editor and choose Annotate from the pop-up menu). See if that person can answer some basic questions for you about how the code is structured. This may not be practical — for example, the developer may no longer be on the project. However, in those cases where it is practical, it is often the simplest way to get the knowledge.

There is also:

  • Read the code comments, if there are any
  • Read the project documentation (e.g., design documents), if there are any