Changes for page Refactoring

Summary

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

Details

Page properties

Content

...	...	@@ -8,8 +8,7 @@
8	8	* **Refactoring requires extensive tests.**
9	9	* **The cost of refactoring is the risk of introducing new bugs**, which can be greatly reduced by a comprehensive test suite.
10	10	* **Stabilize untested code by adding tests.** If you intend to change code that has no tests, the risk of introducing new bugs through refactoring is high. Therefore, the first step is to write tests that capture the behavior of the current code. The second step is to do the actual refactoring. If a bug is introduced, aka the behavior changes, the tests will immediately indicate the problem, so you are safe to move on.
11		-* **Cleanup before change.** If you intend to apply changes to bad code, clean it up first, so that you can apply the changes much more easily.
12		- * For example, your task requires you to change many places in the code in the same way. That means big code changes all at once, which is error-prone and harder to debug. The better way is to abstract the duplication, even into many small, simple steps, which are safe due to frequent testing and staging/committing via git. After that, the original change is much easier to apply, and safer because there are fewer locations in the code to adjust.
	11	+* **Cleanup before change.** When you encounter bad code, clean it up first, and then apply the changes. The changes will then be much easier to implement then. For example, your task requires you to change many places in the code in the same way. That means big code changes all at once, which is error-prone and harder to debug. The better way is to abstract the duplication, even into many small, simple steps, which are safe due to frequent testing and staging/committing via git. After that, the original change is much easier to apply, and safer because there are fewer locations in the code to adjust.
13	13	* **Refactor in small steps.** Whenever tests pass, you should stage or commit your changes using Git. If a bug is accidentally introduced, it is much easier to catch if the code changes were small, and rollbacks never undo much work. Doing lots of small commits is good practice. See also [[TDD|doc:Software Engineering.Agile.Extreme Programming.Test-Driven Development.WebHome]].
14	14	* **Work in two distinct modes during development.** Either add new functionality or refactor, but not both. This ensures that you do not mix up different concerns and that you do not encounter associated problems. When you are done in one mode, commit your changes and switch to the other mode.
15	15	1. **Add new functionality**: Don't change existing code, leave other functionality untouched. Add new tests and functionality.