Changes for page Refactoring

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -20,8 +20,8 @@
20	20	* **Handling Major Changes**: Refactoring should take anywhere from a few minutes to a few hours at most. Anything beyond that is considered a major change.
21	21	* Small refactorings should be done immediately.
22	22	* Major changes should be done by applying many small refactorings on the fly, whenever code that is part of the major change is touched anyway because of work on another feature. Apply these changes within the RGB cycle (see [[here|doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.WebHome]]) whenever you encounter code that needs to be changed in line with the larger refactoring goals. This means that partial refactorings will be in the main branch, or even in production, but this is fine as long as all the tests pass.
23		-* **Refactoring should be spontaneous.** It should happen on the fly, and in the best case, help you with my current task ("prepare refactoring" for the actual new feature). Do not create schedules for refactoring.
24		-* **Sometimes refactor clean code**: As requirements change, even perfectly clean code needs to be changed and re-refactored.
	23	+* **Refactoring should be spontaneous.** It should happen on the fly, and at best, help you with my current task, which is called "preparing refactoring" for the actual new feature. Do not create refactoring schedules.
	24	+* **Sometimes refactor clean code**: As requirements change, sometimes even perfectly clean code needs to be changed and re-refactored.
25	25	* **Preparing refactoring and feature implementation usually belong together**, and therefore in the same branch.
26	26	* Do not perform refactorings if
27	27	* you run into a big mess that you can't easily refactor and that still works.