When I started working with a huge legacy codebase, it was very normal to spend an entire day just reading the code and trying to understand the flow. A year later, I’ve gotten a lot better at it, but sometimes I still find myself dreading to make big changes to the pile of spaghetti code that might break something or everything.
I've spent weeks inventorying code (while also working on new features, granted)
Top-down coding lost its cachet in the '80s, but it's the best way to avoid creating "legacy code": instead of a big mess of spaghetti, at worst one makes lots of little bowls of macaroni, which one can refactor individually
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When I started working with a huge legacy codebase, it was very normal to spend an entire day just reading the code and trying to understand the flow. A year later, I’ve gotten a lot better at it, but sometimes I still find myself dreading to make big changes to the pile of spaghetti code that might break something or everything.
"an entire day" ‽
I've spent weeks inventorying code (while also working on new features, granted)
Top-down coding lost its cachet in the '80s, but it's the best way to avoid creating "legacy code": instead of a big mess of spaghetti, at worst one makes lots of little bowls of macaroni, which one can refactor individually