Code reuse: Reusing complex method vs. cherry-picking parts

Question

I am currently facing a situation where I am not quite sure how to best proceed.

Background

I am planning a new data import process, which will import personnel and salary information from a text file produced by a different system. We already have an import process for the data in question, but the format of the import file will change completely. Thus, while the data that is read will remain the same (employee names, pay grades, past salary payments...), it is expressed very differently in the new file format (different format, different fields, different coding of data, different representation of special cases such as unpaid leave or retroactive changes of salary).

How to reuse?

Now I would like to re-use as much of the existing import code as possible. The problem is that most of the existing classes and methods have parts that could be reused (mostly the parts that deal with writing the data into our own database, which has not changed), but also have many details of the old import format hardcoded, so direct reuse is impossible.

I now see two alternatives:

1. try to refactor and rework the existing code to be more independent of the particular import format, so it can handle both old and new format
2. cherry-pick the parts of the old code that still apply (extract them to separate methods or similar) and reuse that

My problem

I'm finding it difficult to judge which approach is best. On the one hand, I believe reuse is important, and 1) seems to allow me to reuse more. On the other hand, from looking through the code I have a gut feeling that at least 30%-50% of the code no longer apply, so I fear 1) might be a lot of refactoring work, and in the end I'd only reuse little more than with approach 2).

The problem is (I feel ) that I'll have to decide this upfront, because it's difficult to switch approach once I have started: If I start with 1), and after a few day of refactoring I find that little actual "meat" remains in the generalized functions, I have to throw away all the refactorings and start afresh with separate code that calls the old code as needed.

So how do you go about solving new problems when you have code that is broadly similar, but differs in many details to what you need? How do you judge which approach to code reuse makes more sense?

Answer 1

So you have an old import process, and need a new one, for a different data format. The old code is not decoupled from the exact input format.

My advice is to start from scratch, and copy-paste whatever parts are useful. Make sure your new code does decouple the input and output function, and has solid test cases for both. Then, next time you or your successor need a similar function it will be much easier to reuse the code. If possible, use the old code to create an input filter for the old format, testing your decoupling.

Code reuse is a great idea, but reusing bad decisions not so much.

Answer 2

To start answering the problem, this is what I believe your solution would look like. The system would have three functional parts. The core part would be a (reasonably abstract) in memory representation of the data. The second part would be the output logic that would be able to output your data to the database. The third (and most relevant in this case) would be the input logic.

The input logic reads the file and creates the in memory representation. This part is dependent on the input framework. There may be a parsing framework involved (if the format is complex enough to warrant that), which could be reused, but otherwise this part would need to be rewritten.

What you should do depends on your existing code. If it is a big spaghetti that is almost impossible to refactor into such a framework (possibly with parsing utility code), then you would probably have to do a rewrite and cherry pick what is salvageable. If refactoring could work, do that and as added benefit your program can now handle both input formats at the same time, and in a way that makes it fairly straightforward to add another format.

Answer 3

My advice is don't go overboard with code reuse. Sometimes (more often than you think) you think that you should reuse the code in a new place, but in reality it is only here and now that the code you need is the same as the code you have available in the older part of the system. If two components are logically coupled and will develop together (say, different variants of the same business problem), it is usually fine to do some effort to reuse code. If they only accidentally look similar, belong to two different problem domains and may develop along different paths in the future, coupling them via code reuse is going to bring more problems than benefits. In this situation, do not hesitate to Ctrl+C, Ctrl+V.

Answer 4

Why don't you just write something to reformat the new data into the existing input format that you know already works?

Answer 5

I'm going to say go with option #1, but approach it as if it's option #2. You write a completely new system from scratch, and copy the good parts of your old code base. As someone already mentioned, make the input/output format pluggable. Then write your new input/output format.

And then, write an input/output format for your OLD format. Voila. You have option #1 complete. The nice thing about doing it this way is that you can skip the last step (porting old data format) if you're stretched for time.

Answer 6

I do recommend refactoring the code. You essentially have two input formats you need to deal with, and change having a habit of being constant, there will likely be new formats in the future. There's a couple ways of organizing the target code.

1. Refactor and move the business logic into a set of utility functions. That keeps the reusable bits available for both file formats, and depending on how simple/hard those reusable bits are can be the quickest solution. This works best if each function operates directly on the data provided to it. If you need to reference data in another part of the file, you may need to look at option 2.

2. Refactor to separate parsing and consuming data. In other words, have an internal representation of the data that isn't going to change unless you have new requirements. That can have the reusable bits in it, so you can deal with the more complex logic that rely on data in different parts of the object hierarchy. The two inputs merely consume the raw format and convert it to the internal representation. To support new formats only requires adding a new front end parser.

NOTE: only refactor what you will need for the new input format. That minimizes the refactoring overhead, and lets you focus on what's important for the new format.