Pull-Request is not a best practice, it is a custom. It may be a good custom, but it probably not. Pull-Request doesn’t make source-code better, people do.
Get Feedbacks
Do pull-request when you want feedback. And don’t approve it if you not wanna give any. Reviewing code doesn’t mean some social status. The old man learns from youngsters these days.
Don’t Wait
Pull-Request can be a bottleneck. The more reviewer, the longer the developer needs to wait for their work to be approved. The more feedback, the longer the reviewer needs to wait for the revision (then approve it). It is more fun when the two friends sit together.
Ownership VS Responsibility
When a bad code push to the production, who takes responsibility? When good software delivered, who is the owner? Can somebody guarantee things?
Be confident of yourself. You commit good and review right. Committer and reviewer together conquer the world.
Content is King, Context is God
While beautiful code is nice to see, what does code do is more important. Are you run the program when reviewing the code? Are all tests passed?
I just hope all this unit test is easier to understand. Am I reviewing the code or criticizing the unit test?
Less is More
My small head only can hold little information. Commits code immediately after finishing a small task to free some space.
My little eye can see not much. Don’t make it look at your two-days code in a single commit. It beyond what I usually stare.
My tiny brain can’t guess everything and demands some description in the commit’s message.
Deadline and Refactoring
The deadline is coming and we don’t have much time. The show must go on. Luckily, the reviewer fully understands the situation. After the show, we survived.
But don’t be satisfied. Keep refactoring!
Epilog
What choice do I have in this life? Let me review yours and submitting mine.
