It sounds as though your code isn't very well decoupled and/or your task sizes are way too big.

Code changes should be 5-10 files unless you're doing a codemod or large scale refactoring. If a single change touches a lot of files, it probably means that your changes cascade. Some improved abstractions (more single responsibility, interface segregation, and dependency inversion) should help. It's also possible you maybe went too single responsibility and could use a bit more pragmatism - shorter and thinner type hierarchies. That should make the code easier to understand too since you don't have to understand dozens of files to know what the code is doing.

It also might be a sign that your work is too big. Instead of "hey, add this feature" (which requires UI changes and API changes and data access changes and security changes and test changes and...) break it down into more serviceable chunks. That becomes easier to review and easier to understand, because it requires you to set up decent contracts between the bits.

And of course, unit tests help all of this. They force you to make decent interfaces. They force you to make your code flexible enough to inject the bits needed to test (if it's hard to test, it'll be hard to reuse). And they push people away from over-engineering stuff because the more you engineer the more you need to test.

It sounds as though your code isn't very well decoupled and/or your task sizes are way too big.

Code changes should be 5-10 files unless you're doing a codemod or large scale refactoring. If a single change touches a lot of files, it probably means that your changes cascade. Some improved abstractions (more single responsibility, interface segregation, dependency inversion) should help. It's also possible you maybe went too single responsibility and could use a bit more pragmatism - shorter and thinner type hierarchies. That should make the code easier to understand too since you don't have to understand dozens of files to know what the code is doing.

It also might be a sign that your work is too big. Instead of "hey, add this feature" (which requires UI changes and api changes and data access changes and security changes and test changes and...) break it down into more serviceable chunks. That becomes easier to review and easier to understand because it requires you to set up decent contracts between the bits.

And of course, unit tests help all of this. They force you to make decent interfaces. They force you to make your code flexible enough to inject the bits needed to test (if it's hard to test, it'll be hard to reuse). And they push people away from over-engineering stuff because the more you engineer the more you need to test.

It sounds as though your code isn't very well decoupled and/or your task sizes are way too big.

Code changes should be 5-10 files unless you're doing a codemod or large scale refactoring. If a single change touches a lot of files, it probably means that your changes cascade. Some improved abstractions (more single responsibility, interface segregation, dependency inversion) should help. It's also possible you maybe went too single responsibility and could use a bit more pragmatism - shorter and thinner type hierarchies. That should make the code easier to understand too since you don't have to understand dozens of files to know what the code is doing.

It also might be a sign that your work is too big. Instead of "hey, add this feature" (which requires UI changes and api changes and data access changes and security changes and test changes and...) break it down into more serviceable chunks. That becomes easier to review and easier to understand because it requires you to set up decent contracts between the bits.

And of course, unit tests help all of this. They force you to make decent interfaces. They force you to make your code flexible enough to inject the bits needed to test (if it's hard to test, it'll be hard to reuse). And they push people away from over-engineering stuff because the more you engineer the more you need to test.

It sounds as though your code isn't very well decoupled and/or your task sizes are way too big.

Code changes should be 5-10 files unless you're doing a codemod or large scale refactoring. If a single change touches a lot of files, it probably means that your changes cascade. Some improved abstractions (more single responsibility, interface segregation, and dependency inversion) should help. It's also possible you maybe went too single responsibility and could use a bit more pragmatism - shorter and thinner type hierarchies. That should make the code easier to understand too since you don't have to understand dozens of files to know what the code is doing.

It also might be a sign that your work is too big. Instead of "hey, add this feature" (which requires UI changes and API changes and data access changes and security changes and test changes and...) break it down into more serviceable chunks. That becomes easier to review and easier to understand, because it requires you to set up decent contracts between the bits.

And of course, unit tests help all of this. They force you to make decent interfaces. They force you to make your code flexible enough to inject the bits needed to test (if it's hard to test, it'll be hard to reuse). And they push people away from over-engineering stuff because the more you engineer the more you need to test.