Have you ever had to refactor a project that was not documented? Any suggestions?

@andros@twtxt.andros.dev I suggest to not touch it and work on a different project instead. :-D

No, in all seriousness, that’s a tough one. Try to figure out the requirements and write tests to cover them. In my experience, if there is no good documention, tests might also be lacking. It goes without saying that you have to understand the code segments first before you can begin to refactor them. Commit even earlier and more often than usual, this will help you bisecting potentially introduced bugs later on. Basically baby steps.

But it also depends on the amount of refactoring required. Maybe just scrap it entirely and start from scratch. This might not be feasible due to e.g. the overall project size, though.

1st thought… Run!

Well, I’ve heard you have plenty of experience with Unit Testing and TDD. Perhaps designing a few tests before refactoring?

I’ve heard of Snapshot testing, but have never tried it: https://github.com/spatie/phpunit-snapshot-assertions

Also, what kind of refactor are you trying to do?

The project is a POC (Proof of Concept) that went into production and the company has customers who are using it. The developers had been working for several years, without testing, structure, isolation and so on. The company hired me to transform the project into a real product. There are in my hands 422 python files to transform that they beg me a refactore, architecture and testing. Every developer’s bad dream.
My first step is to read and understand the tree because there are apps inside other apps call each other. I am very determined to work on a new repository.

Thanks @prologic@twtxt.net @eapl_en@eapl.me @lyse@lyse.isobeef.org ! I take note

ok, sounds like a ‘large’ project to me.
Is it more an API (more oriented to developers), more oriented to UI/UX/Frontend? Perhaps both?

I’d go with prologic’s advice of measuring and prioritizing. Perhaps you have a budget or at least something like “let’s see how far can we reach in 6 months”, and possibly you won’t finish in the time you have (just guessing).

Something that has helped me was defining “Why do you we want to refactor this project?”.
Could it be to make it compile on newer versions, or making it easier to grow and scale, or perhaps they are trying to sell that product to another company. Every reason has a different path, IMO.