Wiki source code of Refactoring
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | Refactoring means improving the structure of code without changing its behavior. | ||
| 2 | |||
| 3 | * **Consistent Behavior**: To ensure that the behavior has not changed due to a refactoring, all tests must pass afterwards. | ||
| 4 | * **Immediate Refactoring**: Do not allow big messes to emerge, refactor as soon as possible by cleaning up small messes immediately. | ||
| 5 | |||
| 6 | ### Red-Green-Refactor (RGB) | ||
| 7 | |||
| 8 | This is a simple model that describes the iterative [[TDD|doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.WebHome]] and refactoring workflow: | ||
| 9 | |||
| 10 | 1. Write a test that initially fails. (red terminal output) | ||
| 11 | 1. Implement production code to pass the test. (green terminal output) | ||
| 12 | 1. Refactor and make sure the tests still pass. | ||
| 13 | 1. Repeat until done. | ||
| 14 | |||
| 15 | A more complex workflow that includes TDD and versioning with git can be found [[here|doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.TDD Workflow Example.WebHome]]. | ||
| 16 | |||
| 17 | ### Major Refactorings | ||
| 18 | |||
| 19 | For example, a major refactoring could be a large design change to the architecture. Do major refactorings on the fly, in small increments, within the RGB cycle each time something is changed. This means that partial design refactorings will be in the main branch, or even in production, but this is fine as long as all the tests pass. |