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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Ask HN: How do you avoid small misses and mistakes in a PR?

1 点作者 mr_00ff006 个月前
Hello all,<p>I have been working as a software engineer for 3 years now, and I am happy with how much better I have become in that time period. However, I do have one issue that seems to be a constant with me: When I open PRs, I tend to have small misses or tiny changes that always need to be fixed. What I mean is missing something like adding a parameter for logging that all other similar functions of this type have, or doing something in a slightly more complicated way because I am reinventing the wheel when our code base already has something to use that I just couldn&#x27;t find.<p>This hasn&#x27;t been mentioned by a manager or anything, but I can tell compared to the other engineers on my team, I find myself making those mistakes more. I realize to some degree, some of that is inevitbale, but I do feel like my PRs have more than I should.<p>I am wondering what type of habits all you use when starting a ticket. Should I be asking as many questions as possible during planning so I know everything about the ticket before I start? Should I be having a long planning phase before even writing code?<p>Any advice is helpful, thanks

1 comment

robertknight6 个月前
A couple of suggestions:<p>1. Try not to stress too much. The point of review is to improve the quality of the code that lands, and the health of the codebase as a whole, not to grade the author.<p>2. When you think your work is ready for an initial review, take a short break and then review it line by line yourself, looking for any obvious mistakes or possible simplifications. I recommend doing this in a different editor or view than the one you authored the code in originally.<p>When reviewing someone else&#x27;s code, it is annoying if there are silly mistakes that the author could obviously have caught themselves. Issues where the author was not aware of a subtle detail or a coding practice in some other part of the code are less of an issue. Identifying these are exactly what reviews are for.