I changed one method signature and now have over 25,000 errors. What now?

Question

I started a new job recently where I am working on a very large application (15M loc). In my previous job we had a similarly large application but (for better or for worse) we used OSGi, which meant the application was broken down into lots of microservices that could be independently changed, compiled, and deployed. The new application is just one large code base, with maybe a couple of .dlls.

So I need to change the interface of this class, because that's what my boss asked me to do. They initially wrote it with some assumptions that didn't generalize too well, and for a while they have been avoiding the problem of refactoring because it's so tightly coupled. I changed the interface and now there are over 25000 errors. Some of the errors are in classes with important sounding names like "XYZPriceCalculator" which reaaally should not break. But I can't start up the application to check if it's working until all the errors are resolved. And many of the unit tests either directly reference that interface, or are coupled to base classes which reference that interface, so just fixing those is a pretty huge task in itself. Plus, I don't really know how all these pieces fit together, so even if I could get it to start, I don't really know what it would look like if things were broken.

I never really faced a problem like this at my last job. What do I do?

Answer 1

25000 errors basically means "don't touch that". Change it back. Create a new class that has the desired interface and slowly move the consumers of the class to the new one. Depending on the language, you can mark the old class as deprecated, which may cause all sorts of compiler warnings, but won't actually break your build.

Unfortunately these things happen in older code bases. There's not much you can do about it except slowly make things better. When you create the new classes, make sure you properly test them and create them using SOLID principles so they will be easier to change in the future.

Answer 2

Divide and conquer with refactorings

Often, breaking up the change that you need to do into smaller steps can help because you can then perform most of the smaller steps in a way that doesn't break the software at all. Refactoring tools help a lot with such tasks.

Divide

First, identify the smallest possible changes (in terms of logical changes, not in terms of changed LoC) that sum up to the change you want to achieve. Especially try to isolate steps that are pure refactorings and can be carried out by tools.

Conquer

For complicated cases like yours, it may make sense to perform one small refactoring at a time and then let the problem rest, so that all continuous integration systems can verify the change, and maybe the testing team had a look as well. This validates the steps you make.

To carry out a particular refactoring, you absolutely need tool support for a case where you have 25,000 call sites of the method you want to change. Maybe search-and-replace works, too, but for such a critical case, I'd be scared by that.

Example

In C#, for example, it's possible to use Resharper to change the signature of a method. If the change is simple enough, e.g. adding a new parameter, then you can specify which value should be used at call sites that would otherwise have a compile error.

You are then at an error free code base immediately and can run all unit tests, which will pass, because it was a refactoring only.

Once the signature of the method looks good, you can go and replace the values that Resharper added as arguments to the newly introduced parameter. This is not a refactoring anymore, but you have an error-free code base and can run the tests after each line you change.

Sometimes that doesn't work

This is a very useful approach for cases like yours, where you have a lot of call sites. And you do have working software now, so it may be possible to make small refactoring steps to change the signature just a bit, then do another one.

Unfortunately it won't work if the signature change is too complex and cannot be broken down into smaller changes. But this is rare; splitting the problem into smaller problems usually shows that it is possible.

Answer 3

Clarify your task with your boss to help him to understand the problem and your needs as a professional software developer.

If you are part of a team, look for the lead developer and ask him for advice.

Good luck.

Answer 4

Don't touch it. Don't commit anything.

Instead, sit down on your chair and shout "Heeeeelp!!!!!" as loud as you can.

Well, not exactly like that, but ask any of your senior colleagues for advice. If you have 25,000 errors, you don't fix the errors, you fix what caused the errors. And a senior colleague should be able to advice you how to make the change your boss wants without the 25,000 errors involved. There are various ways to do this, but what is a good way depends on your specific situation.

And it might be the boss told your senior colleagues to make that same change, and they said "no". Because they knew what would happen. That's why you were given the job.

Answer 5

Entrenched APIs can't simply be changed. If you really need to change them, anootate and/or document them as deprecated (by whatever means the language allows) and document which API should be used instead. The old API can then be phased out slowly... perhaps very slowly depending on your time budget for refactoring.

Answer 6

Evaluate

Evaluate whether this change is necessary, or whether you can add a new method and deprecate the other.

Forward

If changing is necessary; then a migration plan is necessary.

The first step is to introduce the new method and have the old method massage its arguments so it can call the new one. This may require hard-coding a few things; that's fine.

This is a commit point: check that all tests pass, commit, push.

Migrate

The busy work is migrating all callers of the old method to the new one. Thankfully it can be done gradually thanks to the forwarder.

So go ahead; don't hesitate to use tools to assist (sed being the most basic, there are others).

Mark the old method as deprecated (with a hint of switching to the new method); it will help you spotting whether you forgot anything and will help if a coworker introduces a call to the old method whilst you are working on this.

This is a commit point (or maybe several commit points): check that all tests pass, commit, push.

Remove

After some time has passed (maybe as little as a day), simply remove the old method.

Answer 7

If your change to the method signature is merely a name change, the simple solution is to use tools to automate the change in the 25,000 classes that reference the method in question.

I assume that you have simply edited the code manually, which gave rise to all the errors. I also assume you are familiar with Java (seeing your reference to OSGi), so for example in Eclipse (I don't know which programming environment you use, but other environments have similar refactoring tools) you can use "Refactoring -> Rename" to update all the references to the method, which should leave you with no errors.

In case you are making other changes to the method signature than simply renaming (changing the number or types of parameters), you can use "Refactoring -> Change method signature". However, chances are you will have to be more careful as the other answers suggest. Also, regardless of the type of change it may still be quite a task committing all those changes in a busy code base.

Answer 8

Here my contribution.

I started a new job recently where I am working on a very large application (15M lines of code).

You probably are not familiar with the project and its "features". Before to type down a single line of code, It's important to be familiar with the project. So do rollback your changes and start by analysing the code. (At least the affected one)

Understanding the existing solution gives you a better perspective of where are you getting into. Contextualise the solution and Its importance.

As @Greg pointed out, you should be able to test the existing code to have a valid reference to compare with (regression tests). Your solution should be capable of generating the very same results than the existing one. At this stage, don't you care about whether or not the results are right. The first goal is to refactor, not to fix bugs. If the existing solution says "2+2=42", your solution should too. If it does not throw exceptions, yours should not either. If it returns nulls, yours should return nulls too. And so on. Otherwise, you will be compromising 25k lines of code.

This is for the sake of the retro-compatibility.

Why? Because right now, It's your unique guarantee of a successful refactor.

And many of the unit tests either directly reference that interface, or are coupled to base classes which reference that interface.

A way to guarantee the retro-compatibility is urgently needed for you So here your first challenge. Isolate the component for unit testing.

Keep in mind that those 25k lines of code were made assuming the possible results of the existing code. If you don't break this part of the contract, then you are half way to the final solution. If you do, well: may the force be with you

Once you have designed and implemented the new "contract", replace the old one. Deprecate it or take it out.

I have suggested leaving bugs alone because of refactoring and fixing bugs are different tasks. If you try to take them forward together you may fail on both. You may think you found bugs, however, they could be "features". So leave them alone (for a minute).

25k lines of code seem to me enough issues to make me focus on only one task.

Once your first task is done. Expose those bugs/features to your boss.

Finally, as @Stephen has told:

There's not much you can do about it except slowly make things better. When you create the new classes, make sure you properly test them and create them using SOLID principles so they will be easier to change in the future

Answer 9

Test it.

Everyone else is recommending how to refactor so there is little impact. But with that many errors, even if you succeed in refactoring with as little as 10 lines of code (you probably can), then you have impacted 25,000 code flows, even if you didn't need to rewrite them.

So, the next thing to do is make sure your regression test suite passes with flying colors. And if you don't have one, then make one that will. Adding a comprehensive regression test suite to your monolithic project sounds boring but is a nice way to increase confidence in release candidates, as well as release them faster if the suite is automated well.