DEV Community: Codacy

Applications Open: A Fellowship Program for Open Source Developers

Heloisa Moraes — Wed, 20 Sep 2023 10:14:48 +0000

Here at Codacy, we recognize the importance of the open-source software (OSS) community and are dedicated to nurturing and supporting it in any way we can.

Throughout the history of our company and product, OSS has been at the heart of what we do and how we provide value. lifts the whole world and flattens mountains of knowledge disparity.

That’s why we’ve launched Codacy Pioneers—a fellowship program to fund, promote, and mentor innovative and creative OSS projects worldwide.

Supporting builders is part of our DNA. Through our platform, we help hundreds of thousands of developers with software insights. With Pioneers, we wanted to find new ways to help people build the future.

Projects selected to participate in the program will receive a year-long monthly stipend, free access to the tools they need to work, widespread promotion, and mentorship from some of the brightest minds of today’s OSS community.

We’ve assembled an incredible roster of open-source superstars to mentor and guide our Pioneers on their journey, including:

Vue framework creator Evan You
Enix co-founder Jérôme Petazzoni
Prisma founder Johannes Schickling
CHAOSS community lead Ruth Ikegah
Nakazawa Tech CEO Christoph Nakazawa

With Pioneers, we want to inspire talented builders and tell their stories. We want to remove friction from the process of inventing the future.

Do you have an open-source project you’re incredibly proud of? If so, we’d love to hear from you!

Applications for the Pioneers program are open as of today and close on September 29.

Pioneers will be selected no later than October 16, 2023, by our mentors and engineers.

To apply for the program, head to our Pioneers page and fill out a quick questionnaire to inform us about your project.

This type of initiative is very new to us. And while we don’t know what to expect, we know that helping builders is the right thing to do.

Leave us a comment if you have any questions.

Best of luck to all potential Pioneers!

Code reviews in large-scale projects: best practices for managers

Heloisa Moraes — Tue, 31 Jan 2023 13:29:11 +0000

Managing code reviews for large-scale projects can be challenging, as the volume and complexity of the code might seem overwhelming. However, code reviews are essential for guaranteeing the quality and maintainability of the codebase, as well as identifying and addressing performance bottlenecks.

Today we’ll cover some best practices your team should follow when performing code reviews on large-scale projects.

Divide and conquer

Break the codebase into smaller, manageable chunks and assign specific sections to different team members for review. This will make the process more manageable and ensure you don’t overlook areas of the code. There are several ways you can divide the codebase into manageable chunks:

Functionality-based: Divide the codebase based on the different functionalities or features of the project. For example, you can divide a codebase into the frontend, backend, and database sections.
Modularity-based: Divide the codebase based on the different modules or components of the project. This approach can be especially useful for projects with complex codebases.
Team-based: Assign different sections of the codebase to different teams or team members. This way, they’ll view all areas of the codebase, and no one team member will be overwhelmed.

Prioritize high-risk areas

Identify the areas of the codebase that are most critical to the project's success and focus on these areas first. This will ensure you identify and address potential issues as soon as possible, reducing the risk of delays or setbacks. Here are some ways to identify high-risk areas in a codebase:

Identify areas of the codebase that are most frequently changed or updated. These areas may be more prone to errors and should be reviewed more frequently.
Look for areas of the codebase that are critical to the functionality or performance of the project. For example, you should consider high-risk the code responsible for handling user authentication or sensitive data.
Identify areas of the codebase that are new or untested. New code is more prone to errors, and untested code may contain hidden bugs.
Analyze the codebase using automated tools like Codacy Quality for static analysis, which can help identify areas of the codebase that are most likely to contain errors or bugs.

Once you have identified high-risk areas, prioritize these areas for review, focusing on them before moving on to lower-risk areas. However, prioritizing high-risk areas does not mean neglecting the rest of the codebase but rather focusing on the most critical areas first.

Automate where possible

Automating certain aspects of the review process can make the process more efficient and effective. For example, automated tools can help to identify potential issues in the codebase and standardize the review process, making it more consistent and objective.

With Codacy Quality, your team can make sure the codebase adherence to coding conventions, such as style guidelines. They can also identify potential issues such as bugs, security vulnerabilities, or performance bottlenecks, guarantee code coverage and tackle technical debt.

By automating certain aspects of the code review process, you can make the process more efficient and effective and also standardize the review process.

Communicate effectively

Effective communication can foster a collaborative and productive work environment and make the code review process smoother. Here are some ways to effectively communicate when conducting code reviews:

Set clear guidelines: Establish guidelines for what your team should review and how they should report and track issues. This can help your team understand the expectations and participate effectively.
Make sure everyone understands their roles: Clearly communicate the roles and responsibilities of all team members involved in the code review process. Make sure everyone understands their role and how it contributes to the overall process.
Encourage open communication: Create a culture of transparency and feedback by encouraging open communication between team members. This ensures that any issues or concerns are identified and addressed quickly and can also help to promote team learning and development.
Use code review tools: Your code review tools should support communication and collaboration, like comments and annotations. This will allow your team to have an organized way to communicate and track the progress of the review process.
Provide feedback and recognition: Regularly provide feedback and recognition for the team member’s efforts and contributions, and help them understand their work's impact on the project.

Review regularly

Schedule regular code reviews throughout the development process rather than waiting until the end. This will help identify issues early on and allow for timely course correction, reducing the risk of delays. Here are some ways to conduct regular code reviews:

Establish a schedule: Set up a schedule for code reviews, such as daily, weekly, or after each Sprint. This will help ensure all code is reviewed promptly and any issues are identified and addressed as soon as possible.
Make it a part of the development process: Incorporate code reviews into the development process, such as having developers review their own code before submitting it.
Use a pull-based review process: With a Pull Request review process, developers submit their code for review before they merge it into the main branch. This allows multiple sets of eyes to review the code and can help to identify issues early on.
Encourage CI/CD practices: Automating the testing and deployment of code change, along with regular reviews, allows your team to catch issues early and fix them quickly before they become bigger problems.

Keep in mind that reviewing code regularly throughout the development process also helps to promote a culture of quality and accountability.

Rotate the reviewers

Rotating the reviewers allows all the team members to be familiar with the different parts of the codebase and can provide valuable feedback. It also avoids bias in the review process, as different reviewers may have different perspectives and can identify issues others may have missed. Here are some ways to rotate the reviewers:

Assign different reviewers for different sections of the code: This way, all team members are familiar with different parts of the codebase.
Rotate reviewers for different projects: All team members will be familiar with the codebase of different projects and can provide valuable feedback.
Rotate reviewers for different team members' code: By doing this, all team members will be familiar with the code written by their colleagues and understand their coding style and best practices.

Focus on the learning

Code reviews are not only about finding bugs but also an opportunity for the team members to learn from each other. It's an excellent way to learn new coding practices, best practices, and problem-solving approaches. Here are some ways to focus on the learning during code reviews:

Encourage sharing knowledge: Encourage your team to share their knowledge and best practices during the review process. This can help to promote learning and development among team members.
Use code reviews as a mentoring opportunity: Code reviews are excellent for mentoring junior developers and providing constructive feedback on improving their code.
Promote collaboration: Encourage your team to work together during the review process and share their thoughts and ideas.
Use code reviews to promote best practices: Encourage your team to write readable and maintainable code and to follow best practices.
Use code reviews as a way to learn new technologies: Use code reviews to learn new technologies and approaches and encourage your team to experiment with new tools and technologies.

🎥 [Webinar] Level Up Your Team’s Code Reviews

Join our Engineering Manager Kendrick Curtis and our Lead Account Executive Mark Raihlin in a discussion about helping your team perform their best code reviews.

Join us in our Webinar Level Up Your Team’s Code Reviews. See you there!

👉 When: February 2nd, 2023, 4 pm UTC / 10 am CDT
👉 Where: online – registration needed

Save me a seat

What NOT to do as a developer

Heloisa Moraes — Wed, 25 Jan 2023 10:40:00 +0000

The following views were expressed by a member of our Codacy Community

Before I came to the industry side of the world, I was an academic. I was focused on computer science research (with a special love for software quality) and on teaching students at the university.

From my years in academia, I was able to determine patterns in students when they were writing code. I saw the same patterns from junior to senior developers at different companies. Some of those patterns might be hindering your performance, so let’s take a look at what not to do as a developer:

Jumping into programming right away. Before writing your first lines of code, think about the problem and the proper solution. It might help brainstorm on a piece of paper!
Not updating your knowledge. Programming languages, frameworks, technologies, and techniques change every day. So you need to keep yourself updated and never stop learning.
Forgetting edge cases. Even if your code seems to be working and you added some tests, don’t forget to check for edge cases. It depends on the solution you are working on, but it might be negative numbers, empty strings, different input types, and everything else in between.
Not checking performance and complexity. Most of the time, there are better and simpler ways to go about a particular solution and piece of code. So always check the complexity of your code and if you can improve it. I discussed the Big-O notation in a previous post, so give it a read.
Not reviewing your code. Always review your code, both manually and automatically. With code reviews, your team can find issues early on, share knowledge, distribute ownership, and standardize development practices, among many other benefits. Plus, static code analysis tools like Codacy Quality can effectively reduce heavy lifting and tedious parts of the code review process.

Free to share other things developers should not do 👇

The true impact of technical debt

Heloisa Moraes — Thu, 05 Jan 2023 17:15:12 +0000

Technical debt happens in all software projects, regardless of the programming languages, frameworks, or methodologies. It is a common metaphor for software’s accumulated backlog (like bugs, missing documentation, and legacy code).

There are different types of technical debt, and while some are beneficial to achieve a goal, you’ll need to pay that debt off sooner or later. To help in that process, we shared ways your team can start tackling technical debt while delivering value at the end of each Sprint.

If not addressed, technical debt will compound and cause greater issues in your software. It will impact not only the customer experience but also your team and your business. Today, we’ll dive deeper into the true impact of technical debt.

What is the true impact of technical debt?

The impact of accumulated technical debt extends broadly across different parts of an organization’s ecosystem. It can have serious consequences, like losing customers, making a product more vulnerable to security risks, increasing development costs, and negatively impacting your team’s morale.

Technical debt impacts your code

Increased number of bugs: Defects, issues, and bugs are typical consequences of technical debt. These bugs also impact the product, raising maintenance costs and affecting the customer experience.
Increased complexity: When developers rush to meet a deadline, they may not develop clean and well-organized code. This will make the code more complex than it needs to be, making it more challenging to maintain and more prone to bugs and other issues.
Decreased code quality: Poor design and development practices might allow developers to finish their work in time for tight deadlines. However, they also reduce code quality and create long-run issues. Low code quality will also make it difficult for developers to maintain the codebase, directly impacting the product.

Technical debt impacts your product

Decreased usability and functionality: Some features might fail to work correctly due to technical debt, impacting usability, customer satisfaction, and reputation. It can also increase the downtime of your product.
Increased development cycles: Technical debt can also lead to delays in the development process, as developers may need to spend more time fixing issues and addressing other aspects of the codebase. This can impact the ability to meet deadlines, slow down the build process, and delay the release of new features and updates to the market. In addition, the delays impact customers and teams relying on delivery, like marketing and sales.
Increased security problems: Poorly written code is often poorly secured, which can introduce unexpected vulnerabilities and increase the risk of serious events, such as data security breaches.

Technical debt impacts your team

Decreased development speed: Since developers need to spend time on technical debt, working on and delivering new features takes longer.

Decreased team morale: As technical debt accumulates, it becomes more difficult to understand the codebase and the amount of work needed to add a new feature. As such, technical debt can also lower your team’s productivity considerably. Plus, the team’s morale decreases as the team spends more time fixing preventable problems.
Decreased retention: Unhappy or demotivated developers are more likely to resign, impacting your team’s organization, workload, and overall performance.

Technical debt impacts your business

Decreased customer satisfaction: Technical debt almost always negatively correlates with customer satisfaction due to poor user experience. This translates into an increased expense due to more tickets and customer support and loss of sales and renewals due to lower client retention.
Decreased innovation: When technical debt is severe, developers must continue servicing the issues instead of devoting time to building innovative new features with business value. The team will not be able to adapt quickly to opportunities or changes in the market.
Increased costs: Technical debt can increase the cost of maintaining and improving the codebase over time. This can include the cost of fixing issues and improving performance and the cost of lost productivity due to delays. There are also customer support costs related to clients not being satisfied with the product.
Decreased revenue: Customer dissatisfaction due to technical debt means less client retention and inefficient marketing spending.
Brand and reputation: Ultimately, if technical debt is severe, it can affect the brand and reputation and undermine the business's survival.

Codacy Quality: the best solution for tackling technical debt

We run a DevOps Intelligence Platform that helps thousands of developers ship billions of lines of code per day by automating and standardizing code reviews. We’ve built a suite of products that help developers quantify and act on their software quality, engineering performance, and security.

Codacy Quality is the best-in-class solution for static code analysis. Integrating seamlessly into your workflows, Codacy Quality helps engineering teams save time in code reviews and tackle technical debt. Quality supports 40+ programming languages and is available in free open-source and enterprise versions.

If you’re looking for a static analysis tool that allows you to check your code quality and keep track of your technical debt, start a free 14-day trial of Codacy Quality today.

Dashboard of Codacy Quality

3 popular Python style guides that will help your team write better code

Heloisa Moraes — Wed, 28 Dec 2022 17:04:14 +0000

A code style guide is a set of rules, standards, or best practices that outline how your team should write, format, and organize the source code. In an ideal world, your team’s source code should look like it was written by a single person, even if hundreds of developers collaborated on it.

Being consistent with a style guide makes your code easier to read, debug, and maintain. It is also smoother to add new features or update legacy code, and new developers have an easier integration with the team.

Many programming languages have more than one recommended style guide, and Python is no exception. To help you get started, here are 3 of the most popular style guides for Python that will help your team write code in a consistent way and improve your coding standards.

PEP 8 – Style Guide for Python Code

Python has an excellent style guide called PEP 8 that covers most situations you and your team will find while writing Python. You can use it with PEP 257, which focuses on semantics and conventions associated with Python docstrings.

PEP 8 presents guidelines on naming Python objects, how to structure your code, when to include comments and whitespaces, and some general programming recommendations. This style guide will allow you to have consistency in your Python code, making it easier for everyone in your teams to understand and contribute to the codebase.

However, PEP 8 is a generic Python guideline rather than strict rules that you should follow since it allows different approaches to achieve similar goals. So you’ll need to make sure that everyone in your team follows the same approach in the first place.

The Hitchhiker’s Guide to Python

If you are looking for a community-driven style guide, The Hitchhiker’s Guide to Python is the one for you. However, remember that it might not always be updated and accurate since it depends on the community who writes it.

This style guide aims to give novice and expert Python developers a best practice handbook for installing, configuring, and using Python. It includes recommendations for structuring your project and guidelines for code style, documentation, testing, logging, and more.

Google Python Style Guide

The Google Python Style Guide defines the coding standards used at Google. This style guide has two parts, one focusing on language rules (conventions and coding standards) and the other on style rules (aesthetic formatting issues). It’s a great guide if you have a big team with many developers actively working on a large codebase.

There is also a formatter for Python files called yapf that your team can use to avoid arguing over formatting conventions. Plus, Google also provides a settings file for Vim, noting that the default settings should be enough if you're using Emacs.

Conclusion

When you’re working in a large team with other developers, everyone will have their style of writing code because no two developers write code the same way. If you’ve got different developers writing code differently, your codebase will be almost impossible to understand. Also, onboarding new developers might be harder, as they won’t know the best approach to use.

This is where style guides come to the rescue. A style guide is a set of rules that developers follow when writing their code to ensure consistency among developers. In this article, we’ve covered 3 Python style guides your team can use in your Python projects.

Share your favorite Python style guide with us, and let’s keep the conversation going in our community.

7 best practices for writing great software tests

Heloisa Moraes — Tue, 27 Dec 2022 11:33:25 +0000

An important metric of code quality is how much of your codebase is covered by tests, as we saw in a previous article about code coverage. However, having a good code coverage score isn’t enough.

The quality of your tests influences their effectiveness and can significantly affect the quality of your product. Today, we’ll cover 7 best practices for writing great software tests. Those practices help you get the most out of your testing strategy, so keep reading.

What makes a great software test?

Simple and short: you should be able to understand and execute the tests;
Goal-oriented: focusing on a single output gives clear purpose and meaning to the test;
Consistent: all the tests should be consistent regarding the terms used;
Valid: you should align the tests with the acceptance criteria defined for the requirements;
Maintainable: tests should be easy to maintain and update when requirements change;
Discoverable: you should be able to search and find a test using multiple criteria easily;
Fast: you should be able to execute a test as quickly as possible to reduce effort;

Best practices for writing great tests

#1 – Treat your tests with the same importance as your code

Your tests require the same care and attention you give the rest of your codebase. Like any other part of your code, tests should be regularly evaluated, maintained, and improved.

You should also use comments in your tests and have a defined code review process. Tests take development time, so they should be planned, and you should design them to support and enhance your business' critical infrastructure.

Finally, it would help if you kept your tests organized, as it allows avoiding repetitions. Get yourself and your team familiar with patterns for modularizing test cases.

#2 – Make your tests independent of each other

Tests should never depend on each other. For example, if your tests have to be run in a specific order because some tests depend on others, you need to change your tests to avoid those dependencies.

If, in your system, it’s unavoidable to have some tests dependent on others, try to isolate them as much as possible through pre-conditions. However, this is just in particular cases, and you should avoid it as much as possible.

#3 – Your tests should work individually or in parallel

It’s only natural that your test suite grows along with your codebase. When your test suite gets larger, writing tests you can run individually or in parallel on multiple machines really pays off.

This approach allows you to test only the parts of your code that you or your team changed. You can also better distribute testing resources across multiple machines, which helps you to get results faster. Finally, tests that can work individually or in parallel also mean that you can refactor them without fearing that change will affect other tests.

#4 – Refactor your tests regularly

As with any part of your codebase, you should regularly review and refactor your tests. As such, plan to survey your test suite from time to time to ensure your tests remain relevant and valuable.

When you change, add, or remove functions to your code, verify if the tests still make sense. Usually, with these changes in the code, the data passed into functions also changes, and your tests need to reflect this modification.

#5 – Minimize waits as much as possible

Tests that require “waiting” will likely cause more problems as services interact differently on various machines. In addition, if you run tests often, adding waits to a test suite can make it very slow.

If you’re testing asynchronous code, it sometimes appears to require wait or sleep steps. However, it would be best if you tried to incorporate a library designed to handle asynchronous waits in your programming language.

#6 – Test across the boundaries of your system

Your test suite should always test both sides of a given boundary. Imagine the piece of code you will test as a rectangle. You’ll need to test what happens to points inside and outside the rectangle and at the boundaries. These boundaries are where your code might fail.

If your code depends on external services, don’t forget to prevent problems by testing the boundary layers. This anticipation will allow you to have some control over code you might not have written and have no access to.

#7 – Keep track of your code coverage

Tools that keep track of code coverage, like Codacy Quality, can tell you exactly which parts of your code are covered by tests. This will help you direct your efforts toward pieces of code that lack tests.

To better enforce tests, you can also define thresholds where Pull Requests are not accepted if code coverage is below a specific percentage. Code coverage tools also allow you to track coverage over time, so you can report on and measure the results of your efforts.

[Live Talk] Take Your Code Coverage to the Next Level

If you missed our webinar, watch the recording to learn how you can leverage your code coverage. See how our engineers apply it in their day-to-day.

9 useful APIs for your next projects

Heloisa Moraes — Fri, 23 Dec 2022 12:23:50 +0000

If you have a list of new software-related projects to start or complete in 2023, these tips will make your life easier!

You probably already know what an API is. But if you need a refreshment, API stands for Application Programming Interface, and it’s a way for two or more pieces of software to communicate with each other.

Here’s a list of useful and cool APIs you can use in your next projects:

Brainshop – It helps you create chatbots based on AI. The basic plan is completely free.
Cloudmersive API – This advanced Machine Learning API helps you with your image recognition and processing needs.
Count API – It allows you to create simple numeric counters.
Currency converter It’s a simple API for currency conversion.
Flight API – This API gives you all the information about flights: airport, ticket prices, schedule, and flight status, among others.
NASA APIs – It gives you access to different types of data about astronomy, space weather, the moon, mars, and much more.
OpenWeather – It gives you access to current weather data and hourly, 5-day, and 16-day weather forecasts.
Random user generator API – It allows you to generate placeholder user information. You can get profile photos, names, and more.
Spoonacular API - It allows you to access over 5k recipes, 2k ingredients, and 600k food products you can use to build a great food-related app.

Find more interesting tips and discussions in the Codacy Community.

Feel free to share the APIs you love and use the most 👇

We are doing a Code Coverage Webinar: what would you like to know?

Heloisa Moraes — Wed, 19 Oct 2022 10:05:04 +0000

We’re really excited for next week’s Live Talk on how to Take your Code Coverage to the Next Level. It's only a week away, and you can register here.

If you're a developer, you probably know what code coverage is, and that a well-tested codebase is usually (but not always) a well-structured codebase. But are you leveraging your code coverage reports to achieve the best code quality possible?

Your team can easily overlook code coverage, especially if they are unaware of its benefits and how it impacts their work.

This webinar is made by developers, for the developer community, so your input is really important to us.

What would you like us to cover?

(pun intended)

👉 Share your questions in the comments
👉 Join us on October 25th to discuss code coverage with the engineering and product teams that built our Codacy Quality product 🤖 and see some real examples of how to improve your line coverage

Code Review Best Practices

Heloisa Moraes — Thu, 13 Oct 2022 17:08:40 +0000

We started a code review best practices thread in our community

What about you? Share some of your best practices in the comments 👇

Code reviews are one of the most important aspects of today’s software development workflow. With that in mind, I want to share some code review best practices with you. It is not an exhaustive list, but it can be a good starting point for you and your team.

For code author

Aim for small changes
Group code changes that are related
Read through your code carefully
before submitting it for review
Run tests before submitting the code for review
Use commit templates
Describe the purpose of the code change
Add junior developers to the review to let them learn
Add experienced developers if you need them
Do not add too many reviewers
Be open to comments and suggestions
Show respect to the reviewers
Thank the reviewer for their comments and suggestions

For code reviewer

Give respectful and constructive feedback
Give clear and actionable suggestions or recommendations
Specify the changes that the author needs to make and their level of importance
Ensure traceability for decisions
Give feedback on time
Focus mainly on core issues
Talk directly with the author, if necessary
Reduce multitasking and task switching as it reduces productivity
Don’t forget that great feedback include praise
Use a code review checklist

💡 If you want to dive deeper into code reviews, we created a guide that explains in detail what code reviews are and how to optimize them. We even give you checklists to help you become the best code reviewer you can be. Check it out!

16 Youtube channels for devs

Heloisa Moraes — Wed, 28 Sep 2022 12:07:36 +0000

Here’s a short list of 16 Youtube channels for developers. Whether you are a junior developer or a tech lead, you’ll be able to learn something new from these channels.

For Android developers

Android Developers
CodingWithMitch

For iOS developers

CodeWithChris
Lets Built That App
Paul Hudson

For Web developers

Clever Programmer
CSS-Tricks
The Net Ninja
Traversy Media
Wes Bos

For all developers

Academind
Amigoscode
ArjanCodes
ForrestKnight
freeCodeCamp.org
Programming with Mosh

Did you find this useful? There's a lot more tips like this in our Codacy Community - with over 500+ developers worldwide. Check it out, it's free to join!

9 challenges of managing PRs and how to solve them

Heloisa Moraes — Wed, 14 Sep 2022 15:54:43 +0000

Developers have been using Pull Requests to review code on branches before it reaches master for a very long time. However, this workflow is one of the most challenging and time-consuming parts of the software delivery process.

Every Pull Request comes with different challenges, which can happen before, during, or after the PR is open. In a previous article, we gave you 13 tips to make your PR easier to review. Today, we’ll cover how you can have a better PR workflow by solving 9 challenges you might face.

Before opening the PR

Personnel bottlenecks

Problem: To ensure that high-quality code gets merged into production, some teams only allow some developers to merge PRs. This is well-intentioned, but senior developers tend to get overburdened since they are more knowledgeable. Overwork also increases the likelihood of an error occurring during the review process.

Solution: Include everyone in the code review process. You can use the logic of pair programming in code reviews with senior and junior developers. Everyone will broaden their knowledge of the code base, and the reviews will serve as learning tools where junior developers can improve their skills.

Difficulties in reaching consensus

Problem: Developers sometimes struggle between defending their individual ideas and incorporating contributions different from their vision, either because they don’t agree with the project's direction or the way other developers wrote the code. In those cases, reaching a consensus is challenging.

Solution: Having a shared vision with a clear roadmap about the project's future direction will help developers reach consensus faster. Plus, you can show developers that different ways of writing code are not inherently wrong. If it doesn’t compromise the quality and understandability of the code and if it’s following the agreed coding standards, it should get accepted.

Too extensive Pull Requests

Problem: The more lines of code you need to check, the higher the chance you’ll overlook something. Plus, developers don’t usually thoroughly review big PRs, because they are time-consuming and easier to get lost. As such, it’s fair to say that the bigger the PR, the poorer the code review will be.

Solution: Make smaller and self-contained Pull Requests. Because the PRs are small, it’s easier for reviewers to understand the context and reason with the logic, so the review is quicker and more thorough, and the PR is easier to merge, leading to fewer merge conflicts.

When the PR is open

The code is hard to understand

Problem: Sometimes, developers write code in a way that makes it difficult to understand. If one developer writes unstructured and hard-to-maintain code that other developers cannot read, this will affect the speed of the code reviews and the overall team’s velocity.

Solution: Establish coding standards and guidelines for your code structure and logic. They’ll help your team ship faster and more often since they lead to lower code complexity and more elegant design solutions. Plus, with coding standards, any developer can examine any part of the code, understand it, and change it independently of when and who wrote it.

Lack of information and context on PRs

Problem: When a reviewer opens a PR, all they have is what the author gave him. When there’s insufficient information on the PR description, the reviewer loses the context of the code, making the code review less effective and more time-consuming.

Solution: You’ll save everyone time by providing as much context as possible in a relevant and informative PR description. The most helpful descriptions explain the what, how, and why and give additional information that might help the reviewer in the code review process.

💡Check out tip #6 on how to make your PR easier to review.

A high volume of PRs

Problem: When there are many PRs and not enough people to review them promptly, it can lead to triaging and work prioritization problems. Plus, PRs that are not checked for a long time, while others change the project in terms of functionality, will make it harder to merge without conflicts.

Solution: Set a daily limit on the number of PRs your team can open, and optimize your review workflow. Start by identifying long-running Pull Requests, and check if they still need to be reviewed or if the work doesn’t make sense anymore.

After the PR is open

Lack of response from the author of the PR

Problem: The distributed nature of pull-based development means that a lack of responsiveness on behalf of the PR author hurts the entire code review process, making it slower than it should be.

Solution: Foster a culture where the PR author is ready to respond to comments once feedback starts appearing. By replying, the authors are helping everyone keep track of the feedback that has been seen and considered.

Merge conflicts

Problem: When two developers have made changes to the same set of lines of code, there is a conflict when merging, where the version controller doesn’t know which code to keep and which to discard.

Solution: You can avoid merge conflicts by improving your team’s communication. Use internal communication and project management tools to keep track of the changes and where in the codebase the developers are making them.

A lengthy review process

Problem: A typical PR workflow implies a lengthy series of reviews and tests before you officially deploy the code into production. The process aims to ensure code quality and an alignment between the functionality and the project’s vision.

Solution: Improve the speed of the PR reviews by committing small and often. Plus, ensure that your team understands the importance of code reviews and that they have enough time to perform them. You can help them to meet your expectations by introducing a standard code review checklist.

[Live Talk] Become a Code Review Master

Would you like to hear an expert dive deeper into code reviews? Join Codacy CEO Jaime Jorge in an exclusive talk with Curtis Einsmann, creator of the Master the Code Review course. Let's have an open talk and share our questions.

Join us in our Talk Become a Code Review Master. See you there!

👉 When: September 20th, 2022, 4 pm UTC / 11 am CDT
👉 Where: online – registration needed

Save me a seat

Ask Me Anything about Code Reviews

Heloisa Moraes — Mon, 12 Sep 2022 14:48:09 +0000

We are interviewing former AWS engineer and creator of "Master the Code Review", Curtis Einsmann. What should we ask him?

Hi Dev.to community, let's start an AMA thread.

On September 20th, we will have a live talk: “Becoming a Code Review Master”, with Codacy CEO Jaime Jorge and guest speaker Curtis Einsmann, a software engineer at Gumroad and previously six years at Amazon Web Services. Curtis is an advocate of empathic and effective code reviews, and is passionate about helping developers and organizations level up in that space.

What would you like to ask him? Post your questions in the comments.

👉 Save your spot for the live talk here