Prefactoring: Preparatory Refactoring (2 mins read).
Why I use prefactoring as a means to perform up-front refactoring for codebases, splitting these into separate PRs/MRs where possible.
What to focus on during a code review? Don't waste your time with automatable formalities like code style. Rather spend your review budget on those aspects which will be hard/expensive to change later on. The "Code Review Pyramid" provides some guidance on what to look for.
Gunnar Morling 🌍 (@gunnarmorling)Wed, 09 Mar 2022 19:44 GMT
How to use ArchUnit to codify your technical standards to reduce code review requirements, and arrive at a more consistent codebase.
I like having code review for learning and catching common issues, bugs and missing test coverage, just to name a few, but it's good to read alternative points of view
I've written about this before in https://www.jvt.me/posts/2019/01/12/self-code-review/ and hugely recommend it - especially when there's a way to mark it as a Draft so it's clear it's not yet ready for review. After you've added comments, it may need you to address things before it can then go out to others in the team
Always always review your own PR before sending it to your team to review. I always think I'm done. Then I pretend to be someone else and review it, and I end up fixing 20 issues.
Mae Capozzi (@MCapoz)Wed, 15 Dec 2021 21:34 GMT
Is there a service that anyone knows of that provides third-party code review? I'm wondering if there's a service where a senior developer/engineer would give unbiased feedback. Anyone know of a service or person who does something similar? Thanks in advance.
Ryan Don Sullivan ⤴️ (@ryandonsullivan)Wed, 10 Nov 2021 21:21 GMT
If you think pair programming is inefficient, try waiting hours to get your code reviewed & having to context switch between tasks while you wait. And then switch back when you get the feedback & have to rethink your approach because you weren’t discussing it as you wrote it.
Jez Humble (@jezhumble)Thu, 04 Nov 2021 03:25 GMT
Putting up with poorly motivated nitpicking on my code reviews (after initially fighting back and being told I should cooperate). Then when I gave a critical code comments to that same man, got a huge tantrum about how unfair I was being.
What are some subtle sexist behaviors you noticed or experienced in the workplace?
Cake is Kate. Always has been 💫 (@kefimochi)Fri, 29 Oct 2021 03:33 +0000
Shantini (@_shantini_)Fri, 29 Oct 2021 15:52 +0000
How measuring how long code review took as a team lead to being able to change our processes, and then deliver much more effectively.
Comments that are easy to grok and grep
We've been using emoji for this in the past, which works well as long as everyone remembers what the emoji reflect - I often forget - but doing it this way makes a lot of sense, and having them to be machine-parseable is a benefit!
One of the biggest cultural shifts in my experience from Mozilla to Stripe is code review speed. At Mozilla you'd often wait days and have to hunt down people to review PRs. At Stripe my PR is often reviewed within 10 minutes. That makes a _huge_ difference for shipping fast
James Long (@jlongster)Thu, 03 Jun 2021 17:55 +0000
Not all code review comments should be criticism! Did you learn something new? “Nice! Didn’t know you could do that” Do you have a question? Ask it and don’t jump right to a correction. Async written communication is hard. But it should reflect all your reactions. #devdiscuss
Laurie (@laurieontech)Wed, 19 May 2021 01:17 +0000
We've found it to work quite well on my team, as it allows folks to see things they're not necessarily involved in, and actively seeks out their thoughts, as well as not leaving it up to the PR raiser to decide who
(Although we're currently using the "round Robin" approach)
It also doesn't mean others can't review
Something that no one taught me and I wish I’d learnt on day one: When reviewing PRs, switching between unified or split diff makes them so much easier to parse depending on the type of changes you’re working on. I sometimes switch even within a single PR 🙌🏼
Carol 🌻 (@CarolSaysThings)Thu, 08 Apr 2021 09:52 +0000
A good read - I've found that too many PRs then ends up difficult as you're constantly rebasing them to remove the constant merge commits, so am happy with a larger PR with lots of atomic commits that allow reviewing them in isolation
I’ve reviewed over 750 PR’s at AWS. As my team’s tech lead I provide insightful feedback and enforce a high code quality bar. But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment. Here’s how I review PR’s. 🧵 👇
Curtis Einsmann (@curtiseinsmann)Fri, 16 Oct 2020 17:04 +0000
He brought it up because he noticed a stark contrast between what I comment on and what some others comment on My 2c is that death by 1000 cuts is never worth it for style comments, and they're usually a waste of everyone's time Automate format/linting. You owe it to each other
Kat Marchán 😷 (@zkat__)Wed, 19 Aug 2020 17:01 +0000
Would be interesting for teams to have (informal) code review reviews once or twice yearly to calibrate nit-picking levels and gauge the split in focus between syntax, structure and UX/DX. You can write docs for this stuff but I think many of us can learn from each other.
زهرة || zahra (@zahrataiba)Wed, 12 Aug 2020 11:02 +0000
Performing Code Review on Your own Merge/Pull Requests (4 mins read).
Why the first step to getting others to review your code is to review it yourself.
You're currently viewing page 1 of 1, of 46 posts.