โ† All CAD Flashcard Decks

Code Refactoring and Quality Flashcards

6 cards from real CAD practice questions. Tap to flip, then mark Knew It or Still Learning โ€” missed cards come back until you master them.

Read the first 6 Code Refactoring and Quality flashcards as text
  1. An agile developer is reviewing a colleague's code and notices a method with a very long parameter list. This is a classic example of what?

    Answer: A code smell

    A 'code smell' is a surface-level indicator of a potentially deeper problem in the code. A long parameter list is a well-known code smell, suggesting the method may have too many responsibilities or that the parameters could be grouped into an object. While it contributes to technical debt, the immediate characteristic is best described as a code smell.

  2. According to Martin Fowler, what is the primary definition of code refactoring?

    Answer: Changing the internal structure of software without changing its external behavior.

    Martin Fowler, who popularized the term, defines refactoring as the process of changing a software system's internal structure to make it easier to understand and cheaper to modify without changing its observable behavior. Fixing bugs or adding new functionality are distinct activities from refactoring.

  3. A team is about to add a new feature to their application. They notice the existing code in that area is complex and hard to understand. To make adding the new feature easier, they first restructure the existing code. This is an example of which refactoring strategy?

    Answer: Preparatory Refactoring

    Preparatory Refactoring is the practice of improving the design of existing code specifically to make it easier to add the next feature. The team is refactoring with the immediate goal of simplifying a future development task, which is the essence of this strategy.

  4. Which of the following is a primary goal of code refactoring in an agile environment?

    Answer: To reduce technical debt and improve maintainability.

    Refactoring is a key practice for managing and reducing technical debt. By continuously improving the internal code structure, teams make the software easier to maintain, adapt, and extend in future sprints, which is crucial for agility.

  5. During a sprint, a developer needs to make a change. According to Kent Beck's 'two hats' metaphor, what should the developer do first if the required change is difficult to implement in the current code structure?

    Answer: Switch to the 'refactoring hat' to make the change easy, then switch to the 'adding function hat' to make the easy change.

    Kent Beck's advice, highlighted by Martin Fowler, is to separate the acts of refactoring and adding functionality. When faced with a difficult change, the developer should first put on their 'refactoring hat' to restructure the code, making the change easy. After that work is committed, they switch to their 'adding function hat' to implement the feature itself. This approach keeps commits small, focused, and easier to review.

  6. A team is using the Red-Green-Refactor technique. They have just written the minimum amount of code required to make a failing test pass. What is the immediate next step?

    Answer: Look for opportunities to improve the code's design and eliminate duplication.

    The Red-Green-Refactor cycle, which is fundamental to Test-Driven Development (TDD), has three distinct steps. After writing code to make the test pass (the 'Green' step), the next immediate step is 'Refactor'. This is the phase where the developer improves the internal structure of the code they just wrote, such as removing duplication or improving clarity, while ensuring all tests remain green.