On Code Review
hugodias.substack.com
On Code Review
1–10 of 58 posts
Re: On Code Review
#2[deleted]
Re: On Code Review
#3I also find code review to be an exceptionally effective way of learning a new language, especially languages that have a different mental model from languages you’re already familiar with. I do some Rust training and mentorship, and have found the most effective ways of teaching (once past the basics) to be reviewing their code, giving suggestions on why this pattern might not scale well in Rust, how you can take advantage of ownership here, how to be pals with the borrow checker rather than cloning stuff all over the place there, how expression orientation can make your code neater and more readable, how iterator chaining could help you play to Rust’s strengths, how to work with rather than against Result-based error handling, why you should really give up trying to implement something in an inheritancy way and what an alternative design might be, &c. &c.
Re: On Code Review
#4Hasn't enough been already said and written about the importance and effectiveness of code reviews? Do we really need yet another article on it?
Re: On Code Review
#5"Approving a pull request without even testing the code it’s very dangerous"
Well; code review is not QA. My approval means - I'm OK with how the code layer is knitted. It doesn't mean I've tested the changes.
Of course, if there's some logical problem with the implementation (such as the author seemingly failing to handle an edge case), any careful reviewer should catch this out.
Still, this is a situation where the overlook could be detected through theoretical code analysis, so to speak: which is what a review is. That's not testing.
"some 2~3 line changes may not need to be tested, but those are the exception, not the rule."
Generally speaking everything needs to be tested (not necessarily manually), but that's beyond the point. Testing is not reviewing, and vice versa.
Re: On Code Review
#6Almost everyone agrees that code review is important and worth spending time on, so why don't we think much about our code review tools? Most of us just accept whatever GitHub gives us (esp. smaller or newer teams)
I'm building CodeApprove (https://codeapprove.com) to be a much more powerful, enjoyable, and efficient code review tools for teams on GitHub. If you're interested in trying our Alpha email me.
Re: On Code Review
#7Hasn't enough been already said and written about the importance and effectiveness of code reviews? Do we really need yet another article on it?
Not everyone reads all the articles.
This one has been very useful to me and I'm thankful for the submission.
Re: On Code Review
#8I am really looking for a "code review is a waste of time, let's skip it" article. Seems like there's a market need that isn't being fulfilled.
Re: On Code Review
#9Hasn't enough been already said and written about the importance and effectiveness of code reviews? Do we really need yet another article on it?
Not everyone reads all the articles. This one has been very useful to me and I'm thankful for the submission.
Any software engineering book worth its salt covers this topic. Besides a quick internet search on code review best practices will give you several well written articles. What’s the point of writing and discussing the same thing repeatedly. Seriously move on already! My point is why beat a dead horse. Instead write about something new.
Re: On Code Review
#10I find post-coding, pre-merge code reviews ineffective, for a change.
The code was already written. Time/money spent. Finding out that solution is subpar at this stage is costly, and delaying integration makes ineffective teams.
If you want to enforce standards, automate it (there are multiple highly configurable tools for that). If you want good solutions, pair program. If you want to maintain good codebase, review it periodically (codebase, not some changes to it contained in pull request) and refactor. Use TDD / BDD to ensure the app still works.