What things to refactor first [duplicate]

Question

This question already has answers here:

I've inherited 200K lines of spaghetti code — what now? (19 answers)

Closed 2 years ago.

I do understand this is a wild question and totally open-ended but just wanted to know that I am barking up the right tree.

I've inherited a large code base of many solutions and services, and whilst I'm learning to program in C#, ASP MVC and javascript have noticed a load of issues with the existing code.

I'm being encouraged to refactor the existing code whilst also extending the code base which has almost no tests and some limited documentation. For example one app has tabs but each tab is an individual partial view which has masses of unfactored javascript and decisions made within the view, and uses a cache to store sessions between tabs.

I wondered if I should add tests as possible, refactor the javascript and benefit from this in the existing app whilst rewriting the core app and get to a point where I can transfer the rewritten javascript and other parts to a new better-written tabs website using my tests.

The previous programmers range from novice to good but were coding under pressure, but the company is now far more aware of the benefits of good code and a very good company to work for and they are worth the effort.

Does anyone have a similar experience?

Answer 1

• Use a source control system, and if its already in one, create a new branch for your refactoring work.
• You will need some form of testing to know if you've broken things. How to approach this depends on the nature of what your inherited software does. IF its practical to come up with sample inputs and validate those outputs, you can create a system of regression tests. If it something like a GUI, this is - though still possible - much harder. Maybe just a written test procedure to do on each release?
• If you create a system of regression tests, and CI system may also be of assistance
• Run the code through some automated formatter (like clang-format). If dozens of different programmers have gone through the code, you probably have dozens of stylistic variations. That just uselessly makes it harder to read. Standardize and automate the standard.
• IF you have some sort of regression tests, and or manual test, use a code coverage tool, to get a rough idea what parts of the code are just unused. If its evolved over time, and by immature programmers, there maybe a lot of dead code. Not much point in refactoring the code that never runs. SNIP SNIP!
• At this point, you've done the easy part, and you need to get specific with what the code does, what it does badly, and what you want to fix. But at this point, you have good infrastructure in place to do the fixes.

One problem with a lot of code - especially bad code - is that it lacks modularity. IMPOSE MODULARITY.

How to impose modularity:

(here we are getting C# specific)

Make everything you can get away with private. Separate out the public from the private. I like to rename private members so they end with a _, so that its visually obvious reading the code what is a public and private reference.

When you go around trying to refactor, a good GUIDING LIGHT, is making the public API smaller. Look for where things are done redundantly, or with much verbosity, and look for how you can change APIs so there are fewer, and better, and simpler public APIs.

And - occasionally refer back to the coverage tool. See what code is actually used. If you find your refactoring leads to more dead code - good! CUT CUT! And you can focus on refactoring the parts of the system that see the most use.

That should be a good start (given I haven't looked at the code).