5 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

4 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

3 added 20 characters in body
source | link

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer.

what do you do when you look at your old code

When I look at that code, and the code is working in production, without any bugs - I do nothing. Never!

When I have to maintain or evolve that code, because of bugs or new requirements, then I follow the boy scout rule - leave the code always in a better state behind than the state it was before.

The (sometimes) hard part is: to decide how much refactoring should be applied, how big the scope of the refactoring should be, and how much is enough. To get this right is what makes the difference between an unexperienced and an experienced programmer. I won't elaborate this more here, since there already a lot of posts and articles on the web where this topic has been discussed in detail, see for example here:

2 added 20 characters in body
source | link
1
source | link