IMX it has often been pretty obvious by inspection. If two or more functions do "if {complex condition} then {complex action with only one variation}" any compe

IMX it has often been pretty obvious by inspection. If two or more functions do "if {complex condition} then {complex action with only one variation}" any competent programmer should be able to see that a modification using a common function is equivalent. A slightly more complex case might require more review eyeballs to prove equivalence. Then there are tests. For a relatively small piece of the code you can test quite exhaustively. Most often those tests can live on as permanent unit tests. Occasionally they're so tied to the implementation that they're better thrown away after they've accomplished their purpose. Obviously any but the most trivial refactor requires some care. Is it worth it, when (in the context of OP) you're in there to do something else? Sometimes yes, sometimes no. One rule of thumb is whether you're just rearranging code or changing the fundamental way that it works. Refactors of the first type can generally be kept low-risk and are probably worthwhile. Rewrites of the second type involve more risk and are probably better left to be projects unto themselves.