TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Code reviews do find bugs

221 点作者 _xivi11 个月前

28 条评论

willio5811 个月前
Agreed. I mainly manage and review code at this point in my career. I find many bugs, every once in a while finding something that would have caused an outage or notable problem for users.<p>What I find more though is code that isn&#x27;t thought through. Tech debt and code smell are real, and they affect the performance of a team. Nipping that in the bud takes quality PR reviews and time to meet with submitters around issues you find.<p>Knock on wood but working at the company I do now where I, along with my team, have made quality PR reviews normal.. our codebase is now enjoyable and fun to work on. I highly recommend it!<p>One key aspect is being “kind, not nice”. Be helpful when leaving comments in PRs, but don’t be nice for the sake of avoiding conflict.<p>Also if you find code reviews to be a waste of time I can reccomend one thing I do often - give warnings. I approve and give comments around things I’d like to be fixed in the future for similar PRs. I don’t hold up the merge for little things, but at the same time I won’t let the little things slide forever
评论 #40852681 未加载
评论 #40852469 未加载
评论 #40853512 未加载
评论 #40855925 未加载
评论 #40852398 未加载
评论 #40852569 未加载
godelski11 个月前
I think this is really important in that it is bigger than &quot;code reviews.&quot; It does show how people greatly misunderstand statistics[0]. And what&#x27;s even funny is at surface level the claim that code review &quot;does nothing&quot; __sounds__ ludicrous. But people &quot;believe&quot; because they are annoyed with code review, not because they &quot;actually&quot; believe the results.<p>But statistics are tricky. With the example given in the article &quot;15% of smokers get lung cancer&quot; compared to &quot;80% of people with lung cancer smoke.&quot; These two are not in contradiction with one another but are just different ways to view the same thing. In fact, this is often how people will mislead you (or how you may unintentionally mislead yourself!) with statistics.<p>Another famous example is one that hits HN every once in awhile: &quot;Despite just 5.8% sales, over 38% of bug reports come from the Linux community&quot;[1]. In short this one is about how linux users are just more trained to make bug reports and how most bugs are not system specific. So if you just classify bugs by the architecture of those submitting them, you&#x27;ll actually miss out on a lot of valuable information. And because how statistics work, if the architecture dependence rate was as low as even 50% (I&#x27;d be surprised!) then that&#x27;s still a huge amount of useful bug reports. As a linux user, I&#x27;ve seen these types of bugs, and they aren&#x27;t uncommon. But I&#x27;ve frequently seen them dismissed because I report from a linux system. Or worse, support sends you to their page that requests you to &quot;upvote&quot; a &quot;feature&quot; or bug issue. One you have to login to. I can&#x27;t take a company like that seriously but hell, Spotify did that to me and I&#x27;ve sent them the line of code that was wrong. And Netflix did it to me saying &quot;We don&#x27;t block firefox&quot; but switching user agents gave me access. Sometimes we got to just think a bit more than surface level.<p>So I guess I wanted to say, there&#x27;s a general lesson here that can be abstracted out.<p>[0] Everyone jokes that stats are made up, but this is equally bad.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38392931">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38392931</a>
评论 #40852348 未加载
评论 #40852565 未加载
poikroequ11 个月前
The value of code reviews really depends on the code and the person working on the code. For a team who have spent years working on the same repo, code reviews may not hold much value. But if you have a new guy on the team, or a junior, you&#x27;ll definitely want to review their code.<p>Code reviews can also do more than just find bugs. You can point out a better way of doing things. Maybe this SQL could be more efficient. Maybe you can refactor some bit of code to make it more robust. Maybe you should put a logging statement here. This method name is confusing, may I suggest renaming it to xyz?
评论 #40855878 未加载
评论 #40854530 未加载
评论 #40854064 未加载
评论 #40854892 未加载
jt219011 个月前
I’m not sure why the author ignores the “… that should block a submisson” part.<p>The abstract of the paper:<p>&gt; Because of its many uses and benefits, code reviews are a standard part of the modern software engineering workflow. Since they require involvement of people, code reviewing is often the longest part of the code integration activities. Using experience gained at Microsoft and with support of data, we posit (1) that code reviews often do not find functionality issues that should block a code submission; (2) that effective code reviews should be performed by people with specific set of skills; and (3) that the social aspect of code reviews cannot be ignored. We find that we need to be more sophisticated with our guidelines for the code review workflow. We show how our findings from code reviewing practice influence our code review tools at Microsoft. Finally, we assert that, due to its costs, code reviewing practice is a topic deserving to be better understood, systematized and applied to software engineering workflow with more precision than the best practice currently prescribes.<p>“Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down”<p><a href="https:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;research&#x2F;wp-content&#x2F;uploads&#x2F;2015&#x2F;05&#x2F;PID3556473.pdf" rel="nofollow">https:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;research&#x2F;wp-content&#x2F;uploads&#x2F;...</a>
评论 #40854571 未加载
topkai2211 个月前
Code reviews don’t just find bugs, they prevent them from being introduced in the first place.<p>Developers are more careful about what they write and submit when they know they’ll have someone else looking at it.<p>We went through a couple iterations of our code review policy on a multi-year project a while back. We never really saw code reviews catch a substantial number of bugs over time, but whenever we pulled back on code reviews we definitely saw the production error rate go up.
epolanski11 个月前
My beef with code reviews is that often they lead to tremendous amounts of wasted time, that&#x27;s many thousands spent in a single week sometimes for simple pull requests.<p>Working from 6 years, not much, and not in as many places like others, I have built the opinion that code reviews are like tests, they should be used as a tool when they are necessary, they shouldn&#x27;t be the default for every change.<p>In best case scenarios is the person creating the pull requests that requests reviews or decides the place needs tests.<p>My opinion obviously applies to product software, for libraries, especially when publicly exposed you want as much discussions and tests as possible.
评论 #40852628 未加载
评论 #40852386 未加载
评论 #40872663 未加载
评论 #40854069 未加载
swatcoder11 个月前
As with most processes, the dilemma with code reviews is in figuring out how they impact <i>your</i> team and <i>your</i> organization.<p>In a huge org, with thousands of engineers that&#x27;s already burdened by hours per day of interruptions and process overhead, and release runways that already involve six stamps of bureaucracy, mandatory code revies have very little downside (it&#x27;s in the noise) but highly variable return (many people are just droning under the weight of process). The org loses nothing much for mandating it, but only certain teams will see a lot of value for it.<p>On the other extreme, a startup with five engineers will get backlogged with reviews (which then get shortchanged) because everbody either is under pressure to either stay in their high-productivity flow or put out some pressing fire. The reviews probably could catch issues and share critical knowledge very regularly, but the org pays a pronounced penalty for the overhead and interruptions.<p>People long for &quot;one size fits all&quot; rules, crafting essays and publishing research papers to justify them, but the reality of what&#x27;s right is often far more idiosyncratic.
评论 #40854098 未加载
david2ndaccount11 个月前
In my experience, code reviews catch a lot of bugs. However, if you find yourself catching the same kind of bugs over and over again in review you should be finding ways to catch them automatically without involving a reviewer (static analysis, tests, linters, etc.)
评论 #40852682 未加载
rebeccaskinner11 个月前
I think the article is taking the wrong view. The statistic cited by the article that 15% of comments were about a bug seems in line with expectations, and I think it would only really be worth discussing if the number were _much higher_ or _much lower_.<p>Instead, I think there are two far more interesting questions to ask:<p>1. Is the rate at which code review identifies defects sufficient to use code review as a detection mechanism for defects?<p>After nearly 20 years of writing software, I&#x27;m pretty convinced that the answer here is no. Some reviewers are better than others, and some circumstances are more favorable to finding defects than others, but we should generally try to build processes that don&#x27;t assume defects will be caught at a substantial rate by code review. It&#x27;s nice when it works, but it&#x27;s not a reliable enough way to catch errors to be a load bearing part of the process.<p>2. Is mandatory review of all code justified?<p>This is the one I&#x27;m on the fence about. In an environment where code reviews are high priority, people are trained to review effectively, and there are minimal organizational politics at play, then I hypothesize that allowing PR authors to decide whether to get a review or not would generally improve quality and velocity because code would ship more quickly and code that would benefit from a review would still be reviewed. In that scenario, I think we&#x27;d see the benefits of getting things shipped more quickly when they don&#x27;t require a review, and reviews would be higher quality because code being flagged for review would be a positive sign to pay more attention.<p>Unfortunately, I could be wrong, and it&#x27;s not the sort of experiment anyone wants to risk their reputation pushing for, so I doubt we&#x27;re likely to see an experiment at a large enough scale to know for sure. If we&#x27;re going to fail one way or another, I&#x27;d prefer to fail by doing too much code review rather than not enough.
评论 #40854103 未加载
bluGill11 个月前
Bugs are &#x27;easy&#x27; to fix, I don&#x27;t worry about finding them. I worry about the interfaces as they quickly become a nightmare to change just because of all the users.
评论 #40854110 未加载
29athrowaway11 个月前
If you have a spellchecker, code formatter and a linter, code reviews improve significantly. Much better than having to do that work by hand, or reviewing it by hand, leaving code reviews for higher level ideas.
评论 #40854496 未加载
BlackFly11 个月前
Bear in mind I am pro code review, but...<p>There is a trick in pharmaceutical research where you test a potential candidate drug against placebo to yield a bad study that seems to show benefit. The reason it is a trick is because in many cases the alternative isn&#x27;t placebo, it is an existing treatment. Then doctors learn about a more &quot;modern&quot; treatment, favor it for being modern and the better treatment may not be prescribed.<p>The alternatives to code review aren&#x27;t doing nothing. The article claims that code reviews find a defect per 10 minutes--but only in the first ten minutes. By this same argument (ignore qualifications, extrapolate the numeric result), fast automated testing can potentially find thousands of defects in a second--if they run that quickly and the defects were already tested for. Static analysers, pair programming, documentation these are all alternatives and there are many more.<p>If you&#x27;re spending an hour a day reviewing code then you are spending 12.5% of your time doing it. Using it that way comes with an opportunity cost that may be better spent depending on your particular organization and code base. Of course, analysing everything to death also has an opportunity cost, but not analysing it generally leads to moving goal posts where the supposed rationale for doing something keeps changing. Today its purpose is uncovering defects, tomorrow it is knowledge sharing, the day after it is security. It is all of those things, but other practices may achieve these goals with more effective use of time and people&#x27;s patience.<p>So why am I pro code review? Because choosing to interact and work together as a team, to learn about and compromise with your colleagues makes for good team building while serving other technical purposes. I do think that pair programming can achieve this to a greater level while also being more taxing on individuals. This assumes you control the process and own it though, if it has just become a rote ceremony then my feelings are you probably aren&#x27;t net benefitting from it: you are simply doing it because you have no choice, not because you believe it to be a valuable use of time. If you have experienced both, a culture where people choose and find value in code reviews and a culture where people are forced to do it unquestioningly, then you may have witnessed how a dicta can destroy the prosocial value of a practice.
nitwit00511 个月前
&gt; Developers spend six hours per week reviewing. This is a bit too much<p>It&#x27;s extremely difficult to adjust the time spent on reviews. The options are unattractive. Do you start blindly accepting changes when you hit the limit, or just stop and not let people merge code?
评论 #40859936 未加载
some_furry11 个月前
&gt; During the first 60 minutes of code review of the day, the reviewer finds roughly one defect per ten minutes of reviewing – as long as they review less than about 50 lines of code per ten minutes.<p>Oh.<p>It normally takes me a few <i>seconds</i> to find bugs in code.<p>I always felt this was average performance for assessing software. If the average time is ten minutes per defect, I need to recalibrate my expectations for myself.
评论 #40852935 未加载
评论 #40852920 未加载
grumple11 个月前
I find things wrong with virtually every nontrivial pull request when I’m the reviewer. Sometimes these are minor issues, but I spot bugs and edge cases all the time.<p>I see some comments about time. How long does a code review take? I can review hundreds of lines of code in a few minutes. It is much easier to review code than to write code imo, especially as you gain experience. For bigger efforts, get eyes on it throughout the process.<p>I’ve met a lot of developers who assume their code will just work right after they write it. They don’t test it, via code or manual qa. Then they act surprised when the stakeholder tells them it doesn’t work. Do the job right the first time. Slow is smooth and smooth is fast.
评论 #40853358 未加载
评论 #40854449 未加载
mgreene11 个月前
The paper&#x27;s title is a bit provocative but I think the findings are interesting. Mainly around long-held beliefs about what developers perceive as the value vs what is actually happening.<p>You do bring up a good point about using change defect rate though. I wish the researchers had cited that as the preferred unit of measurement. I did some research on change defect rates on popular open source projects and it&#x27;s all over the map. Ranging from ~12 - ~40% [1].<p>The future I&#x27;d like to see is as developers we use objective measures to justify time investment for review. This is going to be increasingly important as agents start banging out small bug-fix tickets.<p>[1] <a href="https:&#x2F;&#x2F;www.shepherdly.io&#x2F;post&#x2F;benchmarking-risk-quality-kpis-in-popular-open-source-projects#how-often-are-bug-fixes-happening" rel="nofollow">https:&#x2F;&#x2F;www.shepherdly.io&#x2F;post&#x2F;benchmarking-risk-quality-kpi...</a>
sarchertech11 个月前
I remember a time before you needed an approval to merge a PR (I also remember a time before PRs or any widespread version control system).<p>I can count on one hand the number of times someone has caught a bug in my code that should have stopped deployment. Not that I haven’t deployed serious bugs to deployment, but they’ve almost never been caught by someone reviewing my code.<p>Occasionally someone suggests a better way to do something, or asks a question that ends up with me coming up with a better way of doing something. But those situations are also rare. And I can’t think many times at all when the impact was worth the time spent on the process.<p>Pair programming and collaboration can be hugely beneficial, but the minimal effort PR approval culture we’ve developed is a very poor substitute.
评论 #40852491 未加载
评论 #40852379 未加载
评论 #40854116 未加载
sys_6473811 个月前
There are various levels to code reviews. Code review tools that are web based are pretty poor in my experience. Anything more than a few lines across multiple files needs a cscope type tool.<p>Also what type of review? Is this a prototype needing a high level design review so that the actual review doesn’t turn into a design review? How often does that occur?<p>Who are the reviewers and what’s the process? Key stakeholders have more influence and you need to consider the reviewer’s experience, knowledge and credibility.<p>Finally how important is the code? Is it kernel code, or high execution daemon code needing race condition and memory leak checking? Are you using static analysis for the code? Does the code even compile and do what it is designed to do? Where are the unit test logs?<p>Lots to consider.
andirk11 个月前
Technical debt. Keep it minimal, and when needed, write a task for it to be looked in to later.<p>Coding standards. Don&#x27;t submit code that has rando extra lines and things that will slow down the next dev from looking in to the past to learn what does what.<p>And most of all, make sure edge cases are covered, often via a truth table of all possible outcomes.<p>I often comment on a PR saying &quot;blah blah, but not blocking&quot; so I&#x27;ll allow it but at least my entitled opinion was known in case that code issue comes up later.<p>My PRs take a long time, because I dig the F in.
robertclaus11 个月前
I find many standard processes can be described similarly - if you&#x27;re mindful of what problem they solve, they should be incredibly useful. The tricks are the important but subtle details like not spending 2 hours straight reviewing an excessively long PR. Those are easy to forget once it&#x27;s just part of the process.
OpenDrapery10 个月前
I like to see working software alongside a PR. GitLab has the concept of a Review Environment, and it spoiled me. Ephemeral, dynamically provisioned environments that are deployed from a feature branch, are absolutely amazing productivity boosts.<p>It gives so much more context to a PR.
jonobird111 个月前
I&#x27;m not sure code reviews hold much merit. I&#x27;ve been a web developer for around 12 years and I&#x27;ve worked in companies big and small.<p>I think there should be a manual QA process to test the functionality of what the developer is pushing out.<p>The issue with code reviews is always that they take so much time for another developer and many devs are super busy so they just have a quick review of the PR and approve or feel they have to add some comments. Context switching between what the dev is already doing and having to come to the PR to review properly means they should switch to that Git branch, pull down the code, test it all and check for logical bugs that a static code review won&#x27;t pick up.<p>For juniors, code reviews are still useful as you will be able to spot poor quality code, but for seniors, not as much for the reasons above, better off having a QA process to find and logic holes rather than expecting devs to invest so much time in context switching.
评论 #40852981 未加载
评论 #40852954 未加载
评论 #40854113 未加载
dakiol11 个月前
The only thing I don’t like about code reviews are nitpick comments. Everyone has their own subjective way of writing code, if my code works and looks good enough, let it be.
alex_lav11 个月前
Code reviews can find bugs.<p>More often, code reviews become opportunities for team members to bikeshed. Worse, an opportunity for a non-team member to exert power over a project.
评论 #40852493 未加载
评论 #40852666 未加载
评论 #40853076 未加载
Mathnerd31411 个月前
My question is, do human reviewers find more bugs than ChatGPT? Because finding a cofounder costs a lot but asking ChatGPT is free. <a href="https:&#x2F;&#x2F;www.thatsoftwaredude.com&#x2F;content&#x2F;12848&#x2F;chatgpt-can-do-code-reviews-but-are-they-any-good" rel="nofollow">https:&#x2F;&#x2F;www.thatsoftwaredude.com&#x2F;content&#x2F;12848&#x2F;chatgpt-can-d...</a> says it is mediocre, but that was a year ago and honestly mediocre code reviews seem sufficient.
评论 #40852825 未加载
sriharshamur11 个月前
What are some amazing blogs&#x2F;resources to read to learn how to review PRs?
bigcat1234567811 个月前
Hah? Code review of cuz finds bugs... It&#x27;s like people do see...
banish-m411 个月前
Eliminating bugs requires sustained, vigilant, holistic, overlapping approaches:<p>- Code reviews prior to acceptance of commits (Facebook does this)<p>- Refactoring crap that manages to get through<p>- Removing features<p>- Higher-order languages with less code<p>- Removal of tech debt<p>- More eyeballs<p>- Wiser engineers<p>- Dedicating more time to better engineering<p>- Coding guidelines that optimize for straightforward code while not being so strict as to hinder strategic exceptions<p>- Negative LoC as a KPI