Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

This is one of the most basic concepts of refactoring.

At the end of the process it should be more obvious where to find things. Think of an office where there was a big filing cabinet and every time mail arrived people just opened and put the contents of the mail into the big filing cabinet but with no well understood filing system.

Refactoring is the basically a person opening up the big dis-organized filing cabinet and trying to sort things out into smaller well labeled folders so it becomes easy to find things.

That’s it.

No big intellectual mystery about what refactoring is.

For code what does a well labeled folder look like? Best way I have found is name based prefixes.

For example if you had a function in a screen that was related to say “search”. It might involve putting all the functionality related to this function in:

  • A directory named SEARCH (assuming there are no other functions in the software taking that folder) (there isn’t a universal filing system for software)

  • Name the files like image files, SVG files, CSS files, Javascript files and HTML templates to use the SEARCH prefix and be inside of the SEARCH folder

  • Keep the hierarchy flat - don’t have folders inside the SEARCH folder (we’re assuming we aren’t running a software project on the scale of Google)

  • Name all the CSS classes, function names, variables, values stored in a global areas like local storage with the SEARCH prefix.

After this is should be quite easy to find all the dependencies and avoid the accumulation of dead code.

  • No labels