This section covers a brief introduction to programmers and developers who are new to GitHub and never used it since this chapter focuses on the use of GitHub for performing code reviews.

GitHub is a powerful platform that revolutionizes the way developers collaborate on projects. Whether you’re a seasoned programmer or just starting your coding journey, GitHub provides a centralized hub for version control, collaboration, and code sharing. This introduction aims to guide beginners through the fundamentals of GitHub and provide resources to help you embark on your journey to becoming a proficient GitHub user.

What is GitHub?

GitHub is a web-based platform built around Git, a distributed version control system. In simpler terms, it helps you manage and track changes to your code. GitHub extends Git’s functionality by providing a user-friendly interface and collaborative features, making it an essential tool for individual developers and large-scale teams alike.

Here are its key concepts:

• Repositories: These are containers for your project. A repository, or “repo,” holds all the files, history, and documentation related to your project.
• Commits: Each change you make to your project is captured in a commit. Commits help you track the progress of your project and can be accompanied by messages to describe the changes.
• Branches: Branches allow you to work on different versions of your project simultaneously. You can experiment with new features or fix bugs without affecting the main project until you’re ready to merge your changes.
• Pull Requests: When you’ve made changes in a branch and are ready to merge them into the main project, you create a pull request. This allows others to review your changes before they are incorporated.

GitHub’s use within the code review process

GitHub plays a crucial role in the code review process, facilitating collaboration and maintaining code quality within a development team. Here’s an overview of how GitHub is used in the code review process:

1. Pull requests (PRs):
   • Developers typically create a branch for a new feature or bug fix. Once the changes have been implemented, they initiate a pull request.
   • A pull request is a proposal to merge the changes from one branch into another (often from a feature branch into the main branch).
   • PRs encapsulate the changes made, providing an overview of the additions, modifications, and deletions.
2. Reviewers:
   • In a collaborative environment, code reviews involve one or more reviewers who examine the changes proposed in a pull request.
   • Reviewers may include peers, team leads, or anyone with expertise in the code base. Their role is to ensure code quality, adherence to coding standards, and the correctness of the implementation.
3. Discussion and feedback:
   • GitHub’s interface allows reviewers to comment on specific lines of code. This feature facilitates detailed discussions about the proposed changes.
   • Reviewers can suggest improvements, request clarifications, or point out potential issues directly within the context of the code.
4. Continuous integration (CI):
   • Many development teams integrate CI tools (such as Jenkins, Travis CI, or GitHub Actions) with GitHub.
   • CI automatically builds and tests code changes whenever a pull request is opened or updated. This ensures that proposed changes don’t break existing functionality and helps maintain a stable code base.
5. Status checks:
   • GitHub allows integration with various status checks, including automated tests, code style checks, and other custom checks defined by the development team.
   • Pull requests can only be merged if all defined status checks pass. This ensures that the proposed changes meet the project’s quality standards.
6. Iterative improvements:
   • Code reviews often involve multiple iterations. Developers can make additional commits to the same branch in response to feedback and then update the pull request.
   • The iterative process continues until the changes are approved and meet the team’s standards.
7. Merge and deployment:
   • Once the code review process is complete, and the changes are approved, the pull request can be merged into the target branch (for example, main or master)
   • Merging triggers further actions, such as deployment to staging or production environments, depending on the team’s release process
8. History and documentation:
   • GitHub maintains a detailed history of all changes made through pull requests. This historical record is invaluable for understanding the evolution of the code base and tracking who contributed to specific features or fixes.

By leveraging GitHub’s features for pull requests, code review, and integrations with CI tools, development teams can streamline their workflows, catch potential issues early in the development process, and maintain high-quality code bases. This collaborative approach promotes knowledge sharing, code consistency, and overall team efficiency.

Resources for learning

To learn more about using GitHub, coding best practices, and using software methodologies to manage your projects, you can use the following resources:

• GitHub Learning Lab: GitHub provides an interactive learning experience through Learning Lab (https://github.com/apps/github-learning-lab). This platform offers hands-on courses on Git, GitHub, and other related topics.
• GitHub Guides: GitHub Guides (https://guides.github.com/) covers a wide range of topics, from the basics of GitHub to more advanced workflows. The guides are well-structured and easy to follow.
• YouTube tutorials: Numerous tutorials on YouTube cater to GitHub beginners. Channels such as The Net Ninja and Traversy Media provide step-by-step guides for using GitHub.
• Documentation: GitHub’s official documentation (https://docs.github.com/en) is a valuable resource. It covers everything from the basics to advanced topics, providing in-depth explanations and examples.
• Interactive Git tutorial: If you’re new to Git, try the tryGit (https://try.github.io/) interactive tutorial. It’s a hands-on way to learn the basics of Git right in your browser.
• C# coding standards and best practices: Dofactory has a good web page (https://dofactory.com/csharp-coding-standards) that provides C# coding standards and best practices with C# code.
• C# design patterns: Dofactory provides an excellent online resource (https://dofactory.com/net/design-patterns) that covers the gang-of-four (GoF) software design patterns with detailed explanations, UML diagrams, and source code.
• Agile software development methodologies and how to apply them: The Code Project article at https://www.codeproject.com/articles/604417/agile-software-development-methodologies-and-how-t takes you on a journey from the Waterfall method through to the modern Scrum methodology and is an interesting article on choosing the right project management methodology for managing your software projects.
• Code Project: Code Project (https://www.codeproject.com/) is a good place to search for articles, tutorials, and code examples, as well as search for software implementation guidance on topics such as YAGNI, DRY, SOLID, and the software development life cycle (SDLC).

GitHub is an indispensable tool for modern software development, fostering collaboration, version control, and efficient project management. By familiarizing yourself with its key concepts and exploring the recommended resources, you’ll be well on your way to mastering GitHub and enhancing your development workflow.

The normal procedure for carrying out a code review is to make sure your code compiles and meets the requirements set. It should also pass all unit tests and end-to-end tests. Once you are confident that you can compile, test, and run your code successfully, it is checked into the current working branch. Once checked in, you must issue a pull request.

A peer reviewer will then review your code and share comments and feedback. If your code passes the code review, your code review is completed, and you can merge your working branch into the main trunk. Otherwise, the peer review will be rejected, and you will be required to review your work and address the issues raised in the comments provided by your reviewer.

The following diagram shows the peer code review process:

Figure 2.1: The code review process

In the following sections, you are going to read about the code review process in detail. We’ll start by looking at preparing code for review.

Preparing for a code review can be a royal pain at times, but it does work for better overall code that is easy to read and maintain. It is a worthwhile practice that teams of developers should carry out as a standard coding procedure. This is an important step in the code review process as perfecting this step can save you considerable time and energy in performing the review.

Note

When working on a piece of code, you can create a draft PR. Your colleagues can then review the code without having to approve it. This is a good way to receive early feedback as you progress through the development or maintenance of the code. If your coding practices are in the process of being adopted, it is a good way to ensure those new practices are being followed. Once your work is ready for final submission and approval, you can publish your draft pull request. You can learn more about draft PRs on the GitHub website: https://github.blog/2019-02-14-introducing-draft-pull-requests/.

Here are some standard points to keep in mind when preparing your code for review:

• Always keep the code review in mind: When beginning any programming, you should have the code review in mind. So, keep your code small. If possible, limit your code to one feature, and always follow the coding standards.
• Remember YAGNI: As you code, make sure to only add code that is necessary to meet the requirement or feature you are working on. If you don’t need it yet, then don’t code it. Only add code when it is needed and not before.
• Check for duplicate code: If your code must be object-oriented and be DRY and SOLID, then review your code to see whether it contains any procedural or duplicate code. Should it do so, take the time to refactor it so that it is object-oriented, DRY, and SOLID.
• Use static analyzers: Static code analyzers that have been configured to enforce your company’s best practices will check your code and highlight any issues that are encountered. Make sure that you do not ignore information and warnings. These could cause you issues further down the line.
• Make sure that all your tests pass, even if your code builds: If your code builds but you have failing tests, then deal immediately with what’s causing those tests to fail. Then, when the tests pass as expected, you can move on. It is important to make sure that all unit tests pass and that end-to-end testing passes all tests. It is important that all testing is complete and gets the green light since releasing code that works but was a test fail could result in some very unhappy customers when the code goes to production.

Note

Most importantly, only check your code when you are confident that your code satisfies business requirements, adheres to coding standards, and passes all tests. If you check your code as part of a CI pipeline, and your code fails the build, then you will need to address the areas of concern raised by the CI pipeline. When you can check in your code and the CI pipeline gives the green light, then you can issue a pull request.

If you’re new to software development and may not know what CI/CD pipelines are, we will briefly describe them before we go any further.

CI, continuous delivery (CD), and continuous deployment (CD) are three software development practices that focus on improving the speed, quality, and reliability of software development processes. While these terms are sometimes used interchangeably, they represent different stages of a software delivery pipeline:

• Continuous integration (CI): CI is the practice of frequently merging code changes from developers into a shared repository, followed by building and testing the code automatically. The goal of CI is to identify and fix issues as early as possible in the development process to prevent the accumulation of bugs and technical debt. With CI, developers can integrate their code changes into a shared repository multiple times a day, ensuring that the code is always in a releasable state.
• Continuous delivery (CD): Continuous delivery is an extension of CI that focuses on automating the release of software to production. It is the practice of always keeping the code base in a releasable state and deploying it to production frequently, usually via an automated pipeline. With continuous delivery, developers can continuously deliver new features, bug fixes, and improvements to users in a fast and efficient manner.
• Continuous deployment (CD): Continuous deployment is the most advanced stage of the software delivery pipeline and is where every change that passes through CI/CD is automatically deployed to production without any manual intervention. This process is only suitable for organizations that have a high degree of automation, test coverage, and confidence in their code base. Continuous deployment enables organizations to release features and updates to users in real-time, with little to no downtime.

In summary, CI ensures that the code base is always working, continuous delivery automates the release process, and continuous deployment takes automation one step further by deploying code changes to production automatically.