From 0a64bdba436fda76bdd47f2194ef9fbe5a9623d2 Mon Sep 17 00:00:00 2001 From: SloaneTribble <100537368+SloaneTribble@users.noreply.github.com> Date: Thu, 28 Mar 2024 10:50:19 -0700 Subject: [PATCH] Fix a few last typos (#485) * Fix a few last typos * TRUNK-based development, not truck --- .../5.3.1-branching-merging.md | 2 +- .../5-software-development-practices/5.5.7-code-review.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/5-software-development-practices/5.3.1-branching-merging.md b/docs/5-software-development-practices/5.3.1-branching-merging.md index d5d4b627..5139e7d7 100644 --- a/docs/5-software-development-practices/5.3.1-branching-merging.md +++ b/docs/5-software-development-practices/5.3.1-branching-merging.md @@ -54,4 +54,4 @@ A branch should be created only if required. This is most applicable when delive Merging should happen as frequently as possible. As teams improve on creating smaller stories and engineers develop a clear way of working around pull requests, developers can merge code multiple times per day. --- -By eliminating long-lived branches and merging smaller changes directly into a main branch, teams can reduce merge conflicts and release code quicker. This approach is known as **truck-based development**. To achieve this kind of fast-paced development, without sacrificing quality, it is important to have confidence in the quality of code being committed. This can be accomplished by including automated testing in the continuous integration process. We will cover automation and testing in more depth later in this chapter. +By eliminating long-lived branches and merging smaller changes directly into a main branch, teams can reduce merge conflicts and release code quicker. This approach is known as **trunk-based development**. To achieve this kind of fast-paced development, without sacrificing quality, it is important to have confidence in the quality of code being committed. This can be accomplished by including automated testing in the continuous integration process. We will cover automation and testing in more depth later in this chapter. diff --git a/docs/5-software-development-practices/5.5.7-code-review.md b/docs/5-software-development-practices/5.5.7-code-review.md index b8d17179..f05d05ed 100644 --- a/docs/5-software-development-practices/5.5.7-code-review.md +++ b/docs/5-software-development-practices/5.5.7-code-review.md @@ -49,7 +49,7 @@ When seeking out a reviewer, you should try to get a review from someone who is When you're reviewing code, your goal is to help find any potential defects in the code and help the developer make their code be the best it can be. This can feel pretty intimidating if you haven't done it before, but there are some things you can do to try to give structure to your review. -- **Consider writing a checklist.** You could write a checklist of things you're looking for when you're going into a code review. This list could include things like whether or not the code is secure, if it accomplishes the task it says it's meant to, etc. +- **Consider writing a checklist.** You could write a checklist of things you're looking for when you're going into a code review. This list could include things like whether or not the code is secure, if it accomplishes the task it says it's meant to, etc. - **Think about if now is the right time to do a review.** Sometimes you might not be in the right headspace to do a code review. Doing a code review while you're tired or frustrated could result in you missing bugs/errors in the code, or making less than polite comments. @@ -57,7 +57,7 @@ When you're reviewing code, your goal is to help find any potential defects in t ## Specific Guidelines -If you're working in a small team without dedicated code review guidelines, consider taking some time to formalize your groups approach. Some good questions to ask to guide what you want your process to look like could include: +If you're working in a small team without dedicated code review guidelines, consider taking some time to formalize your group's approach. Some good questions to ask to guide what you want your process to look like could include: - How should a developer seek out a reviewer? @@ -67,9 +67,9 @@ If you're working in a small team without dedicated code review guidelines, cons - Should reviewers put forth particular code suggestions? -- Who's responsibility is it to make changes to PRs that need small fixes? +- Whose responsibility is it to make changes to PRs that need small fixes? -If you're working in an organization that already has code review customs put into place, take some time to familiarize yourself with that particular process before reviewing code or asking for a code review. +If you're working in an organization that already has code review customs put into place, take some time to familiarize yourself with that particular process before reviewing code or asking for a code review. ## Examples and Other Resources