What you will learn in "Looks Good to Me"
Constructive code reviews
Chapter by chapter
Concepts explained in this book
- code reviewThe code review process is the organized set of rules, roles, workflows, and practices governing how code reviews are performed.
- pull requestA pull request, also called a merge request, is a proposal to integrate code changes into a target codebase or branch while supporting review, discussion, and approval.
- feedbackFeedback is information or opinions shared to help another person or team evaluate and improve work.
- Team Working AgreementA team document that records shared expectations for collaboration and code review behavior.
- pair programmingPair programming is a software-development practice in which two programmers collaborate simultaneously on the same task, typically sharing one work context.
- knowledge transferThe deliberate process of moving knowledge from one person or group to another.
- mob programmingA software-development practice in which more than two team members collaborate simultaneously on the same problem through a shared work context.
- automationAutomation is the execution of tasks by software, machines, or other systems with reduced or no direct human intervention.
- code review feedbackA code review comment is a reviewer’s written observation, question, suggestion, or request concerning a code change.
- pull request descriptionA concise, high-level account of the changes, affected files, and review focus in a pull request.
- pipelineA workflow is an ordered sequence of activities and handoffs used to complete a process.
- documentationWritten material that explains software behavior, usage, implementation, or relevant reference information.
- maintainabilityCode maintainability is the ease with which software code can be understood, modified, debugged, and extended safely.
- code review policyAn approval policy is a rule set specifying who may approve pull requests and how many approvals are required before integration.
- memory boundA workflow constraint that limits throughput or delays progress through a process.
- comment signalA comment signal is a marker or convention that communicates the required status or priority of a code-review comment.
- style guideA style guide is a document specifying conventions for the formatting, naming, and organization of source code.
- Emergency PlaybookAn Emergency Playbook is a reference guide containing formal actions and decisions for handling urgent situations that require bypassing a regular process.
- refactoringAI-assisted restructuring of code directly within a code-review workflow while proposing an immediately integrable change.
- pairing sessionA pairing session is a bounded collaborative programming period in which two programmers work together on a task.
- artificial intelligenceThe field of computing concerned with systems that perform tasks requiring capabilities associated with human intelligence.
- CodeRabbitAn AI-driven code-review platform that reviews pull requests, posts feedback, and supports code-related conversations.
- lintingA software tool that analyzes source code to detect stylistic, structural, or potential quality problems without executing the program.
- ready for review stateA pull-request status indicating that code changes are properly prepared, self-contained, and ready for review by other developers.
- code suggestionA proposed modification to source code generated or presented to improve its implementation.
- PR feedback chatAn interactive conversation about feedback on a pull request.
- code readabilityThe ease with which developers can understand the structure, intent, and behavior of source code.
- co-authored-by commit trailerA Git commit-message trailer that identifies an additional author of the committed changes.
- personality matchThe compatibility between collaborators' preferred interaction and working styles.
- AI PR AgentQodo's AI component for executing commands against pull requests and generating review-related artifacts.
- automated reviewAn AI-assisted assessment of a submitted pull request that produces an overall analysis and review feedback.
- code walkthroughAn explanatory summary that relates a pull request's overall changes to the individual files affected.
- Copilot for PRsA GitHub Copilot capability that generates summaries and review-oriented information for pull requests.
- issue validationThe assessment of whether a pull request's code changes satisfy the aspects specified in a linked work issue.
- machine-learning-suggested editA proposed source-code modification generated by a machine-learning model in response to a code-review context.
- QodoA software-development tool that provides AI-assisted pull-request descriptions, suggestions, reviews, and conversations.
- review mechanismA review system is a structured mechanism that organizes how code changes are submitted, reviewed, and approved.
- ping-pong pair programming styleA pair-programming style in which participants alternate turns, commonly by writing tests and implementing the code that satisfies them.
- PomodoroA pair-programming style that divides work into timed coding intervals separated by breaks, with roles switching between intervals.
- tag-team pair programming styleA pair-programming style in which participants take over from one another through planned or need-based handoffs.
- accountabilityThe obligation of individuals or a team to take responsibility for their decisions, work, and results.
- 5p processThe 5P process is a code-review decision technique that pauses and considers whether to pass, propose, or postpone an objective suggestion.
- MMG ExchangeA structured discussion for reconciling different implementation preferences by seeking a clear and maintainable solution.
- reviewerA person who evaluates proposed code changes for correctness, clarity, context, and alignment with applicable criteria.
- pull request templateA reusable template that structures the information and checks requested in a pull request.
- objective code review commentA code review comment supported by verifiable facts, requirements, conventions, use cases, or demonstrated effects.
- pull request privilegeAn authorization that allows a person or group to approve a pull request.
- AI-assisted code reviewA code review tool that applies artificial-intelligence techniques to analyze proposed code changes and provide review feedback.
- ESLintAn open-source JavaScript and TypeScript linting tool that detects coding errors, style violations, and other source-code problems.
- driverThe pair-programming role responsible for controlling the active development environment and writing or editing code.
- navigatorThe pair-programming role responsible for guiding the driver, reviewing the current work, and considering broader implementation concerns.
- linter ruleA linting rule is a configured criterion that a linter applies to source code to detect a particular pattern or violation.
- code review expectationsThe understood responsibilities and standards governing what participants are supposed to do during a code review.
- review creepThe introduction of extra changes or work during code review that falls outside the scope of the original work.
- subjective code review commentA code review comment based primarily on personal preference rather than an objective requirement, convention, or demonstrated defect.
- precheckAn automated validation performed before or when a code change is submitted for review.
- politeness principleA code-review communication principle that promotes collective, request-oriented, contextual, and respectful wording.
- psychological safetyA team condition in which people feel safe to ask questions, seek clarification, and contribute ideas without fear of negative consequences.
- blocking issueAn issue judged sufficiently serious that it must be addressed before a pull request can be approved.
- driver-navigator styleA pair-programming style in which one participant guides or explains the implementation while the other performs the coding.
- mob reviewA code-review practice in which a group jointly examines a code change through a shared view and real-time communication.
- historical artifactA persistent record of past work or decisions that preserves their history for later reference.
- complexityThe degree to which a code structure has numerous or intricate elements and relationships that make it harder to understand or change.
- DORAA software delivery performance measure covering deployment frequency, change lead time, time to restore service, or change failure rate.
- reviewer assignmentThe process of selecting and assigning people or groups to review a proposed code change.
- baseline workflowA baseline workflow is a documented representation of the currently understood steps in a process that serves as a reference for comparison and revision.
- comment consolidationThe practice of combining duplicate code-review observations into a single distinct issue or weakness.
- weakness walkthroughA collaborative review of a process workflow in which each identified weakness is discussed and replaced with an agreed-upon solution.
- lead timeThe elapsed time from committing a code change until it successfully runs in production.
- before/after comparisonA presentation that contrasts the state of a software artifact before and after a change.
- context/justificationAn explanation of the reasons, circumstances, decisions, and alternatives behind a code change.
- self-approvalThe approval of a pull request by the person who authored that pull request.
- Conventional CommentsA convention for structuring code-review comments with labels and standardized wording that communicate intent and priority.
- MoSCoW techniqueA MoSCoW comment is a code-review comment classified using must-have, should-have, could-have, or will-not-have priority categories.
- categorization prefixA short phrase or abbreviation at the beginning of a pull request title that classifies the type of change.
- capture-and-chronicle approachA code-review pattern that records the decisions and context produced during collaborative development for later reference.
- PR validatorAn automated check that validates pull-request metadata or organization against configured team rules.
- human-in-the-loopThe human capacity to evaluate software decisions using nuance, context, history, and broader situational understanding.
- quality gateA required validation or authorization that must be completed before a software change can advance in a delivery process.
- personal attackA hostile or critical statement directed at a person rather than at the work or its technical properties.
- technical discussionDiscussion focused on the technical properties, behavior, or implementation of software rather than on a participant’s character.
- team dynamicsTeam dynamics are the patterns of interaction, communication, trust, and cooperation among members of a team.
- cognitive overheadAdditional mental effort required to understand, evaluate, or act on information beyond the task's essential reasoning.
- title-driven reviewA review approach in which the pull request title provides enough context for a reviewer to understand what is being reviewed.
- communicationThe exchange of information and meaning between participants through shared messages and interpretation.
- author's contractA set of responsibilities requiring a pull-request author to self-review, provide a manageable and understandable change, and respond constructively to feedback.
- manageable pull requestA pull request constrained into a short, atomic, complete, and feasible unit of change that reviewers can examine effectively.
- self-reviewA review in which an author systematically examines their own proposed code changes before submitting them to other reviewers.
- CODEOWNERS fileA repository configuration file that associates changed file paths with the people or teams responsible for reviewing them.
- architectural problemA defect in the high-level structure or design approach of an application.
- expected issueA typical code-review problem that reviewers are expected to identify and discuss.
- tough issueA difficult code-review problem whose discovery may require significant rework, delay, or acceptance of technical debt.
- requirementsA requested capability, behavior, or constraint that software is expected to satisfy.
- technical debtThe future maintenance and remediation cost created by accepting an expedient or suboptimal software decision.
- triple-r patternA structured pattern for organizing a code-review comment so that the reviewer remains focused on the code and communicates productively.
- senior developerA developer recognized within a team for substantial experience, expertise, and responsibility in software development.
- feedback cultureA team environment in which people can openly give, receive, and act on honest feedback without fear of interpersonal harm or retaliation.
- revisionSubstantial modification of proposed software changes to address concerns about their implementation, scope, or correctness.
- driving school pairing styleA pair-programming style in which the navigator gives the driver detailed, direct, and tactical instructions.
- bugAn error or flaw in software that can cause incorrect, unsafe, or undesirable behavior.
- signoff conditionA condition that must be satisfied before a code change is formally approved or integrated.
- informational reviewerA reviewer assigned to a pull request for knowledge-sharing purposes whose approval is optional but who is expected to acknowledge reviewing it.
- bus factorThe minimum number of knowledgeable team members who would have to become unavailable before a project stalls because of insufficient knowledge.
- offline conversationA direct discussion conducted outside the asynchronous code-review thread, typically in real time between the relevant participants.
- update commentAn update comment is a code-review comment that records the status, decision, or outcome of an offline discussion related to a proposed change.
- nonblocking issueA code-review issue that may be recorded without preventing approval or integration of the change.
- accuracyThe proportion of AI-generated findings or suggestions that are correct according to the relevant evaluation criteria.
- vulnerabilityA weakness or problem in software that can be exploited to compromise confidentiality, integrity, availability, or control.
- code ownershipA person or team designated as responsible for reviewing changes to specified parts of a codebase.
- loopholeA gap or weakness in a code review process that allows required review controls to be bypassed or applied inconsistently.
- code coverageA measure of the proportion of source code elements or execution paths exercised by tests.
- recordkeepingThe systematic creation and preservation of records that capture the context, details, and history of work.
- lazy code reviewA code review performed with insufficient examination to reliably identify relevant defects, risks, or improvement opportunities.
- formatterA formatter is a software tool that automatically reformats source code according to specified formatting rules.
- review focusThe set of concerns and properties that reviewers are expected to examine in a code change.
- reviewer poolA group of people eligible to review and approve proposed code changes.
- code review usefulnessThe degree to which code reviews achieve their intended outcomes, such as finding problems and improving software quality.
- single senior developer reviewer problemA code-review workflow problem in which one senior developer is expected to review every pull request.
- milestoneA planned intermediate checkpoint at which a developer’s work is reviewed during implementation rather than only at final submission.
- code review timeThe amount of elapsed effort or duration required to examine and evaluate a proposed code change.
- guidelineA guideline is a recommended rule or principle that directs how code reviews should be conducted and how unclear situations should be handled.
- approverA person authorized to approve a proposed code change for integration.
- emergency scenarioAn emergency scenario is a code-review situation requiring an exception to the regular approval process because urgent circumstances make that process impractical.
- GitHubA web platform for hosting Git repositories and collaborating on software development, including pull-request workflows.
- GitLabA web-based software-development platform that hosts Git repositories and provides collaboration and delivery workflows.
- code smellA code smell is a recognizable symptom in source code that suggests a possible design, maintainability, or implementation problem.
- distributed teamA software team whose members work from separate physical locations and collaborate through communication technologies.
- git handoverA remote-collaboration technique for transferring active programming work between participants through a temporary Git branch and work-in-progress commits.
- emergency procedureA predefined procedure for handling urgent software changes or operational situations outside the normal process.
- label managerA pull-request validator that automatically applies labels based on pull-request attributes such as age.
- due diligenceThe careful and thorough attention required to fulfill professional responsibilities and assess work appropriately.
- atomic changeA software change that forms a self-contained unit of work with a narrowly focused purpose.
- CollaboratorA commercial peer code and document review tool that provides review tracking, reporting, audit management, and defect tracking.
- CrucibleA collaborative code-review tool that supports reviewing changes across version-control systems.
- GerritAn open-source web-based code-review tool for Git repositories, implemented in Java.
- Review BoardAn open-source web-based code-review tool that can be self-hosted or consumed as a hosted service.
- RhodeCodeA source-code collaboration tool that supports code review across Git, Mercurial, and Subversion repositories.
- code review cultureThe shared attitudes, norms, and organizational support surrounding code review within a development team.
- rationaleThe part of a code-review comment that explains why the requested change is warranted.
- requestThe part of a code-review comment that states the change the author is asked to make.
- resultThe part of a code-review comment that specifies the measurable end state expected after a change.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.