I usually concentrate on building up my program as I'm writing it, meaning that I optimize while I'm writing this code. For example, I see that a structure owns a
Vec, while it could really be a slice, so I make the change and immediately try to
cargo check it. This ends up in a slower workflow, but it results less to worry about later, when you're thinking about the program as a whole. Then, when you want to add another feature or thing, it should build on top, therefore making it a rather modular system. In this case, the largest changes you may encounter are filename (or mod) changes, or movement of files, etc.
But, in the case where you do end up making a change to your system which will inevitably require refactoring, (One of my previous projects was rather complex type system-wise, so a minor change would mean going through 3 trait impls and a few separate functions to make the changes), then noticing patterns in the changes is useful, like for example if I have many types which all implement a trait in a similar fashion, then cycling through them making the respective change is useful. Another thing to minimize the overwhelming amount of errors is to not make too many changes at once, instead focusing on one at a time, because in certain cases a change which builds on another change may lead to the realization that the original change is impossible to do, and you need to abandon it.
I believe that the best tips I could offer are the following to minimize the amount of long/tedious refactorings you're doing:
- Keep your mod-system tidy. Make sure that everything is compartmentalized and there's no spaghetti. In fact if there is spaghetti, then fix that first before any optimizations.
- Don't be afraid to rewrite a small portion (like a module or an impl) to benefit the usability.
- Use a good IDE, where you can do things like rename a type, or look at references to a function, type or field. I'd recommend IntelliJ IDEA with the rust plugin or vscode if you don't like to wait around for things to get done by the IDE on startup and debugging.
- Piggybacking on the previous point, use an environment where you can click on the error paths, to see what the problem is in the file without having to navigate to it.
Those are my tips on how to make refactoring easy.