Class 6 - Refactoring & Pair Programming

Question 1

Refactoring

Answer 1

The process of restructuring code while not changing its original functionality

Question 2

When does refactoring happen in the context of TDD?

Answer 2

First, developers need to add a test. Then, they need to write code to make the test pass. Only then can developers refactor code (make it clean)

Question 3

Two Hats metaphor for refactoring

Answer 3

Programmers can choose between two “hats”: a refactoring “hat” and an adding functions “hat”. They can swap frequently between hats; however, they can only wear one hat at a time.

Question 4

TDD Refactoring

Answer 4

The most common type of refactoring programmers use.
1. Write test
2. Make test work (focus just on adding a new functionality without worrying about code structure)
3. Refactor (concentrate on good design)

Question 5

Litter-Pickup Refactoring

Answer 5

Cleaning up a messy area of the codebase

Question 6

Camp Site Rule (Litter-Pickup Refactoring)

Answer 6

Always leave code better than when you found it

Question 7

Comprehension Refactoring

Answer 7

Changing a piece of code to make it easier to understand for other developers. Easy to understand code is cheap to use and modify.

Question 8

Preparatory Refactoring

Answer 8

Changing existing code to prepare the codebase for a new functionality you will add in the near future. This allows you to implement new features more efficiently than if you do not prepare for the new feature

Question 9

Planned Refactoring

Answer 9

Scheduling refactoring as part of your team’s planned work (e.g. refactoring stories). Commonly used to fix larger pieces of problematic code that needed dedicated attention.

Question 10

Long-Term Refactoring

Answer 10

Refactoring that spans multiple iterations over several months. Since all changes are refactoring, the codebase can remain in a working state even as new features are added. Examples include: replacing a large module, or changing your database persistence framework

Question 11

When is it a bad idea to refactor your code?

Answer 11

If you do not believe you will recoup your investment later by quicker work later on

Question 12

What is a common sign you need to refactor your codebase?

Answer 12

If your codebase is difficult to understand and modify, and it is slowing you down, that is a sign you need to refactor to improve your efficiency

Question 13

Pair Programming

Answer 13

Two programmers working together on the same task

Question 14

What are the benefits of pair programming?

Answer 14

• Knowledge sharing
• Reflection
• Keeping focus
• Code review “on-the-go”
• Two modes of thinking
• Collective code ownership

Question 15

Reflection (Benefit of Pair Programming)

Answer 15

Pair programming encourages discussing instead of just thinking. Saying and explaining things out loud pushes us to reflect

Question 16

Keeping focus (Benefit of Pair Programming)

Answer 16

It is easier to get distracted when working solo. Working in a pair can prevent you from spending too much time on something that is not important.

Question 17

Knowledge Sharing (Benefit of Pair Programming)

Answer 17

People working together share knowledge to solve a problem. Two minds discussing a problem increases the likelihood a solution will be found.

Question 18

Code review “on-the-go” (Benefit of Pair Programming)

Answer 18

Another person reading the code increases the chances that an error/typo will be caught. Refactoring is more natural with two different perspectives

Question 19

Two modes of thinking (Benefit of Pair Programming)

Answer 19

• Driver (person coding): Brain in “tactical” mode
• Navigator: Thinks more strategically

Question 20

Collective code ownership (Benefit of Pair Programming)

Answer 20

Pair programming ensures that every line of code was touched or seen by at least 2 people. Result: Anyone on the team feels comfortable changing code almost anywhere.

Question 21

What are the different pairing styles in pair programming?

Answer 21

• Driver and Navigator
• Ping Pong
• Strong-Style Pairing

Question 22

Driver and Navigator

Answer 22

Driver (writes code): Talks through what they are doing, thinks about task at hand
Navigator (reviews code): Gives directions, shares thoughts, and thinks about large issues/bugs/next steps

Question 23

Ping Pong

Answer 23

• Person A writes a failing test
• Person B writes the implementation to make it pass
• Person B writes a failing test (for some other feature)
• Person A writes the implementation to make it pass
  (Repeat cycle above as necessary)

Question 24

Strong-Style Pairing

Answer 24

Similar to the “Driver and Navigator” style with more defined roles:
- Navigator: Person with more experience
- Driver: Novice (with the language/framework/codebase)

Eventually, it should be possible to switch roles (since knowledge transfers from navigator to driver)