code-review

TL/DR If you want your pull requests to be taken seriously you probably need to learn some more advanced git features like interactive rebase and squash. First I wanted to share an article I found when helping folks that struggle with code review/pull request comments like “Can you rebase that” or “I don’t want to see all your workings – please squash your commits”. If that applies to you, I suggest you have a read of Git Interactive Rebase, Squash, Amend and Other Ways of Rewriting History....

In addition to my previous post about how to do better code reviews below is a list of specific things to watch out for during code reviews, in no particular order: All the CI builds are green The diff/pull request should be small enough that it is reasonable to review it in under 30min - avoid giant whitespace changes. The entire app build is scripted and available with one click/script CI builds are clearly named and well organised, with separate build/test, deploy and acceptance tests stages Deployment is 100% automated New code does not introduce unnecessary duplication....

Code reviews, the process of showing your hard work to another developer and having them tear it to shreds, are often an unloved part of the modern development cycle. The project manager asks why you would change the working solution, the tester refuses to test something twice, and you have to make your colleague admit on closer inspection their masterpiece has an awful double chin. However it doesn’t have to be that way; code reviews can become part of the daily process and you and your colleagues might start looking forward to showing each other work and sharing knowledge....