Skip to Content

Changes for page Refactoring

Last modified by chrisby on 2024/01/17 21:43
From version 1.8
edited by chrisby
on 2024/01/13 18:24
Change comment: There is no comment for this version
To version 1.7
edited by chrisby
on 2023/11/28 21:18
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -3,8 +3,17 @@
3 3  * **Consistent Behavior**: To ensure that the behavior has not changed due to a refactoring, all tests must pass afterwards.
4 4  * **Immediate Refactoring**: Do not allow big messes to emerge, refactor as soon as possible by cleaning up small messes immediately.
5 5  
6 -###
6 +### Red-Green-Refactor (RGB)
7 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 +
8 8  ### Major Refactorings
9 9  
10 10  For example, a major refactoring could be a large design change to the architecture. Execute large refactorings by integrating many small, incremental refactorings into your regular implementation tasks. Apply these changes within the RGB cycle whenever you encounter code that needs to be changed in line with the larger refactoring goals. 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.