Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Why Do Code Review and What Does It Actually Find? From Bug Hunting to Knowledge Sharing
The main output of code review is not bugs but code that stays understandable and knowledge that spreads through the team: only 14 percent of 570 review comments studied at Microsoft were about defects, and the largest group was code improvements. The post covers the Microsoft and Google studies, the four goals of review, alternatives such as pair programming and Ship/Show/Ask, and the Bookstore team's review agreement kept in the repository.
Making Review Easy as the Author: Small PRs, Stacked PRs, Good Descriptions and Self-Review
The most effective way to make review easy is to keep each pull request small and single-purpose: 2059 of the 2721 lines in the coupon pull request were generated migration files, and splitting the rest into three stacked pull requests for refactoring, model and behaviour reduced each to one question. The post covers GitHub's native stacked pull requests, the template, drafts and self-review, and review rounds with fixups, --update-refs and range-diff.
What to Look for as a Reviewer: Reading Order and a Practical Checklist for .NET + Angular PRs
A reviewer should read a pull request in the order description, design, details, and look not only at the diff but at the code it affects. In a coupon pull request with green tests, that order finds an N+1 and a module boundary violation, an unchanged rule that allows negative totals, a UTC bug, a test that repeats the implementation, a migration that zeroes old orders, an e-mail address in the logs and a stored XSS in Angular.
Communication in Code Review: Comment Tone, Conventional Comments, Disagreement and Review Fatigue
A good review comment addresses the code rather than the person, gives its reason and states clearly whether it blocks the merge; Conventional Comments does this with labels such as issue, suggestion, question and praise, plus blocking and non-blocking decorations. The post rewrites the comments on the coupon pull request in that format and covers how many nits are too many, the author's reply, how to handle disagreement and review fatigue.
The Review Process on GitHub: CODEOWNERS, Rulesets, Suggested Changes, Merge Queue, Bots and Metrics
On GitHub the review agreement moves into the platform through CODEOWNERS, rulesets and team assignment; but two teams on one CODEOWNERS line mean 'either of them', and a second required approval is set up with the ruleset's required reviewers rule. The post shows a ruleset JSON kept in the repository, suggested changes, merge queue with the merge_group trigger, the labeler and Dependabot, where Copilot approvals fit and a tool that derives review metrics from gh output.