Tweeted twitter.com/StackSoftEng/status/1059098110994145281
2 added 7 characters in body; edited tags
source | link

I practice TDD and refactor aggressively. Recently some colleagues have complained that the resulting pull requests are difficult to review, or would require a lot of regression testing.

When I refactor, I'm disciplined about using safe, behavior preserving refactorings, mostly around changing names and extracting methods. When someone says "this will need a lot of testing", I show them how I got there and the reply is "oh, I guess that doesn't need a lot of testing", so my method is sound from a quality perspective.

But, I look at my own pull requests and put myself in a reviewer's shoes and I see where they're coming from. The steps aren't necessarily obvious and the resulting change may be relatively large (say 8 files).

If you practice XP or TDD and refactor aggressively, how do you make your pull requests reviewer friendly?

I practice TDD and refactor aggressively. Recently some colleagues have complained that the resulting pull requests are difficult to review, or would require a lot of regression testing.

When I refactor, I'm disciplined about using safe, behavior preserving refactorings, mostly around changing names and extracting methods. When someone says "this will need a lot of testing", I show them how I got there and the reply is "oh, I guess that doesn't need a lot of testing", so my method is sound from a quality perspective.

But, I look at my own pull requests and put myself in a reviewer's shoes and I see where they're coming from. The steps aren't necessarily obvious and the resulting change may be relatively large (say 8 files).

If you practice XP and refactor aggressively, how do you make your pull requests reviewer friendly?

I practice TDD and refactor aggressively. Recently some colleagues have complained that the resulting pull requests are difficult to review, or would require a lot of regression testing.

When I refactor, I'm disciplined about using safe, behavior preserving refactorings, mostly around changing names and extracting methods. When someone says "this will need a lot of testing", I show them how I got there and the reply is "oh, I guess that doesn't need a lot of testing", so my method is sound from a quality perspective.

But, I look at my own pull requests and put myself in a reviewer's shoes and I see where they're coming from. The steps aren't necessarily obvious and the resulting change may be relatively large (say 8 files).

If you practice XP or TDD and refactor aggressively, how do you make your pull requests reviewer friendly?

1
source | link

Making pull requests easier to review while practicing XP and refactoring

I practice TDD and refactor aggressively. Recently some colleagues have complained that the resulting pull requests are difficult to review, or would require a lot of regression testing.

When I refactor, I'm disciplined about using safe, behavior preserving refactorings, mostly around changing names and extracting methods. When someone says "this will need a lot of testing", I show them how I got there and the reply is "oh, I guess that doesn't need a lot of testing", so my method is sound from a quality perspective.

But, I look at my own pull requests and put myself in a reviewer's shoes and I see where they're coming from. The steps aren't necessarily obvious and the resulting change may be relatively large (say 8 files).

If you practice XP and refactor aggressively, how do you make your pull requests reviewer friendly?