Hi Teiva, any thoughts or readings recs on handling a codebase that has already grown organically to the point of chaos? It's easy to see the benefits of a harmonious codebase, but sometimes I feel like I'm trying to pull out the weeds in a jungle, so to speak.
Balancing consistency with re-writing bad patterns is quite tricky!
I’d say first thing would be to reorganize the code into coherent modules/packages with clear coupling across those and clear APIs. Chaotic code often lack cohesion. It’s the prerequisite before anything else.
Second, chaotic code often sits on top of terrible tests. So, I would make sure the tests are in a shape that would be good enough to catch possible regressions due to code rewrite.
From there, the code sits on stronger foundation. Applying the boy scout rule I described can be a good approach to refactor one small step at a time.
Hi Teiva, any thoughts or readings recs on handling a codebase that has already grown organically to the point of chaos? It's easy to see the benefits of a harmonious codebase, but sometimes I feel like I'm trying to pull out the weeds in a jungle, so to speak.
Balancing consistency with re-writing bad patterns is quite tricky!
Interesting question.
I’d say first thing would be to reorganize the code into coherent modules/packages with clear coupling across those and clear APIs. Chaotic code often lack cohesion. It’s the prerequisite before anything else.
Second, chaotic code often sits on top of terrible tests. So, I would make sure the tests are in a shape that would be good enough to catch possible regressions due to code rewrite.
From there, the code sits on stronger foundation. Applying the boy scout rule I described can be a good approach to refactor one small step at a time.