Question 1

What is refactoring, and how is it different from rewriting?

Accepted Answer

**Refactoring** is changing the internal structure of code **without changing its external behaviour**. That definition, from Martin Fowler, is precise and the constraint is what makes it refactoring rather than something else.

**If behaviour changes, it is not refactoring** — it is a change, possibly a bug. This matters practically: a pull request described as "refactoring" that alters behaviour is mislabelled, and reviewers will not be looking for what actually changed.

**Why do it.** Code degrades as requirements accumulate — abstractions stop fitting, duplication spreads, functions grow, names stop describing what things do. Refactoring restores structure so that future changes remain cheap. It is maintenance of the ability to change, not cosmetic tidying.

**Common refactorings:** extracting a function or class, renaming for clarity, removing duplication, replacing conditionals with polymorphism, introducing a parameter object, and inlining an abstraction that turned out to be unnecessary — which is as legitimate as adding one.

**What makes it safe.** **Tests.** Refactoring without a test suite covering the behaviour is not refactoring; it is rewriting and hoping. Tests are what let you verify behaviour is unchanged, and their absence is the main reason people are afraid to improve code. Where coverage is missing, write **characterisation tests** capturing current behaviour first — including behaviour that looks wrong, since something may depend on it.

**Work in small steps**, with the tests passing between each. A large refactoring that cannot be stopped halfway is a rewrite.

**Rewriting** replaces a component or system with a new implementation. It is sometimes correct — when the architecture cannot accommodate a requirement, or the technology is genuinely unsupported.

**Why rewrites are risky.** They consistently take far longer than estimated; the old system contains years of accumulated fixes for cases nobody remembers; and during the rewrite the old system must still be maintained.

**Incremental replacement** — the strangler pattern — is usually safer.

Question 2

What is the difference between a monorepo and multiple repositories?

Accepted Answer

Whether all of an organisation's code lives in one version-controlled repository or in many — and the trade-off is between coordination cost and isolation, with tooling determining whether either

Question 3

What is a code review actually for?

Accepted Answer

Not primarily for catching bugs — which is the assumption most reviewers bring and the reason so many reviews are unsatisfying for everyone involved. What the evidence and practice suggest reviews

Question 4

What is test-driven development, and does the evidence support it?

Accepted Answer

A practice of writing a failing test before the code that satisfies it, in a short cycle — red, green, refactor. The evidence for its claimed benefits is mixed and weaker than advocates suggest,

Question 5

What are design patterns, and do they still matter?

Accepted Answer

Design patterns are named, reusable solutions to recurring design problems — vocabulary for structures that experienced developers kept independently reinventing. The idea was popularised by the 1994

Question 6

What does "immutable" mean and why does it help?

Accepted Answer

An immutable value cannot be changed after it is created. Operations that appear to modify it return a new value instead, leaving the original intact. Why this helps, and the reasons compound: You

Question 7

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Related Questions