This is a short and sweet story about important facts to know and share about code quality and code reviews. You can also read more about this in our ebook . 680 companies were asked about their code quality and practices. Below are 10 of the most learnings. code review compelling Disclosure: , the automated code reviews platform, has previously sponsored Hacker Noon. For Hacker Noon readers, they’re Codacy offering 15% off using this code: HACKERNOON . The facts 1 We spent a significant amount of time reviewing code. In fact we spend on average 12.5**% of our week looking at code**. 5 hours per week reviewing code or 2As a developer, spending more than reviewing code with improvements in perceived code quality OR in more time shipping new features (as opposed with fixing bugs or paying back tech debt). a day a week doesn’t correlate Diminished returns: spending more than a day per week reviewing code does not correlated with better perceived code quality 3 45% of developers say that ‘ while . Lack of Time’ is the real obstacle to reviewing code 34% say ‘Pressure to Ship’ 4 say that their code reviews are (don’t ship a line of code without being reviewed). 72% of developers blocking 5 . 25% require 2 people. Less than 5% require more than 2. 66% of developers require 1 person to approve their pull requests 6 to approve a pull request. 53% of people monitor code coverage but 65% don’t have a minimum threshold of code coverage 7 say the while VPs of Eng and Directors say “ ”. The third biggest problem for developers is “ ” 29% of developers biggest problem in their project is “Workload” Delivery speed Management Who gets to review code? Two thirds of companies prefer the all hands on deck approach to code review. 8Regarding who gets to review code, having is the most common practice. Other alternatives are having owners of projects or modules or having senior developers review most of the code. everyone in the team do it 9 lead to and Less strict code reviewers spend 31% of their time fixing bugs whereas stricter reviewers spend 24%. Regarding time focusing on new features: 43% and 54% corresponding. Stricter code reviews less time fixing bugs more time delivering new features. 10Developers spend vs of building new features. 45% of their time fixing bugs or addressing technical debt Time spent on average per activity during development You can also read more about this and other great learnings in our new ebook about code reviews: Click to get the ebook
