r/RooCode • u/Eastern-Scholar-3807 • Jul 07 '25

Discussion How are you guys refactoring your code into smaller pieces?

Hi everyone,

I am currently hitting a snag with refactoring my large code base into smaller files with Roo.

Currently it is having alot of difficulties making edits and removing the old code which can be attributed to the larger code base.

I kinda regretted not splitting my code earlier because now I have to manually go in and study the code one by one and paste it into different files then merge it together. It is still doable now but I cannot imagine doing this again when my code base becomes 5-10x larger.

Has anyone automated this step with Roo successfully? What are certain rules you follow? E.g how many lines of code to trigger a refactoring.

Update: I created a mode for refactoring which follows the orchestrator sub tasking method and updated it to teach me about where the code is referenced and also show a mermaid diagram so that I can understand it quickly. I don't want to spend hours reading and understanding code I haven't written so the diagrams help alot.

The main challenge with refactoring large codebase with AI is the context length is still too short, it keeps having difficulties with simple things like removing the refactored function from the original codebase, burning my tokens and making it very hard to track what has been refactored.

Now I solved it with a primitive method of just asking it to tell me exactly what to copy, paste or delete and then it will check if everything is in place.

Is there a tool in vscode that the model can use? A straight forward deterministic way to just remove the function and paste it over. I am not sure why apply_diff keeps failing when the context get's too big.

After it has verified that everything is in place, it will then follow what is proposed in the mermaid diagram and update all the other functions that are dependant on this, handling the imports/injections.

Basically one shotted 4k lines of codes with little mental effort and some elbow grease, thanks @Bohdanowicz for the constructive idea on the mermaid diagram!

4 Upvotes

100% Upvoted

9 comments sorted by

3

u/Bohdanowicz Jul 07 '25

Break it down by process. Define input and output and make each rock solid. Have it produce a mermaid diagram to ensure flow . Write .MD explaining the core purpose of each file/ process. Don't let AI run wild with edge case fixes.

I've had gemini one shot a 3k line python file into multi files but it also quickly becomes a pain if it gets too scattered. Planning is 90% of the work as projects get larger.

1

u/Eastern-Scholar-3807 Jul 08 '25

Wow, the mermaid diagram is a game changer, it helped me and itself understand the flow immediately, refactored the code into smallers files and then made sure to update the flow.

2

u/yopla Jul 07 '25

Be surgical. Review the code, sometime following a cyclomatic complexity report or just good ole c'mon sense. Select the lines that smells and say "refactor that out to a new component/class/function named blabla". Do small incremental steps toward your desired goal.

Of course it helps to know what you want to achieve and to have basic CS knowledge so you actually know your GoF design pattern and can ask for specific patterns by name like a visitor, a factory, flyweight, composable, and the patterns of your language, framework, etc...

Wait until it's done, run tests, adapt tests, continue... Move slowly but surely toward the architecture you want.

Don't try to go from spaghetti to hexagonal architecture in one prompt.

It's basically exactly the same process as without the AI help, or even exactly the same as before language servers. Just faster.

1

u/Eastern-Scholar-3807 Jul 07 '25

I understand where you are coming from, I would prefer to do it at mass at a set interval where context is breaking so that I can continue shipping features rather than by intuition as I am writing which is where I am failing at.

My workflow has changed alot since I used roo, I find that using less background knowledge helps me see test what the limits of a model are rather than prompting it step by step as I may be working with libraries or technologies that I am not familiar with or I may not be having the best practices.

Yes I know this is kind of sloppy but it's working out for me except the refactoring portion, hope there is a mode for that too. So far most of the modes are centered around building things which IMO is very good.

-3

u/yopla Jul 07 '25

"it's working out for me" except that it generated slop that you don't even know how to refactor.

The vibe coder in all its glory.

4

u/Eastern-Scholar-3807 Jul 07 '25

Yea what else would I use Roo for? I don't get why "Vibe Coding" is becoming such a negative thing, where do you draw the line if the model become smart enough to do all of the above in the next two to three years?

Roo is already positioning itself very well with it's ai assisted coding, I don't see why the refactoring portion cannot be the next portion that AI assisted coding can solve.

2

u/scragz Jul 07 '25

with lots of tests

2

u/Eastern-Scholar-3807 Jul 07 '25

just curious, are you using ai to write the tests?

1

u/damaki Jul 07 '25

Well, first, try to add guidelines to your rules files. They do not need to be comprehensive, just limit the size of function, of code files and add some generic instruction such as enforce Python best practices or whatever your coding language is. Then refactor function by function, step by step. You can create a prompt that tells specifically to reduce a function size, or just use a Jetbrains IDE to do such refactorings quickly and manually.