0

The project I am working on has a status field which currently only allows YES or NO, and I am about to refactor it to allow the value MAYBE. Unfortunately, it is used over 1,000 times in 200+ files.

Typically the status field is just displayed raw, but occasionally there is some logic that goes along with it. Because of this, I want to manually review each instance of this field*.

Short of creating some sort of checklist with all 1,000+ instances of the variable and checking each one off as I review them, are there any standard strategies or tools that would allow me to be able to keep track of which references to this variable I have/haven't reviewed?

For this question I am assuming that I can easily find every instance this field is referenced in the project (all have the same variable name yesNoStatus). Unfortunately the project is in a dynamically typed language with poor tooling.

Note: My current strategy is to use a simple find/replace to change all variable names from yesNoStatus to yesNoXStatus, and then remove the X as I review them.

  • 4
    Specifying the environment (language, editor) may be important. Approaches that one would use in Visual Studio working with a C# project would often differ from one working with vim on a Ruby project. – Arseni Mourzenko Nov 9 '18 at 23:03
2

If you are using a compiled language with static type checking, where the compiler will complain if you forgot to change the variable name back, your overall strategy seems to be ok. Note, however, even if you are working in such an environment, you need to test your changes. Hopefully you have enough automatic tests which cover most of the changed code. If not, good luck.

Code which accesses the same status field in 1000 places is IMHO a "design smell". You may consider to look for ways to reduce the number of places where this happens. Some kind of encapsulation of the field in a module might be start. It might be also worth a try to investigate if the number of accesses are caused by a lot duplicate code, which could be refactored into a reusable function or module.

That way, next time you have to deal with such a field, you may not have to check 1000 places, but only 100 or less.

2

To simplify, I'd do this refactoring module by module. If possible, I'd also leverage the IDE features, such as find usages, change-of-signature refactoring, and so on.

For example, you could do the following in IntelliJ, and probably other IDE's by JetBrains. In the project window, choose a module and then Replace in Path. Tick Regex and replace yesNoStatus with //todo yesNoMaybe \n yesNoStatus. This will insert the line //todo yesNoMaybe above each yesNoStatus in the module. The IDE's TODO tool window will list all these (and other) todos and enable easy navigation. Then just delete the //todo line once done.

This could be easier than renaming yesNoStatus and back. Whether this is useful or sufficient would depend on the specifics, such as the language, static vs. non-static typing and the dependencies/usages of yesNoStatus.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.