Skip to Content

Changes for page Refactoring

Last modified by chrisby on 2024/01/17 21:43
From version 1.11
edited by chrisby
on 2024/01/17 21:16
Change comment: There is no comment for this version
To version 1.14
edited by chrisby
on 2024/01/17 21:43
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -8,7 +8,8 @@
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.** When you encounter bad code, clean it up first, and then apply the changes. The changes will then be much easier to implement.
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.
12 12  * **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]].
13 13  * **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.
14 14   1. **Add new functionality**: Don't change existing code, leave other functionality untouched. Add new tests and functionality.
... ... @@ -19,8 +19,8 @@
19 19  * **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.
20 20   * Small refactorings should be done immediately.
21 21   * 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.
22 -* **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.
23 -* **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.
24 24  * **Preparing refactoring and feature implementation usually belong together**, and therefore in the same branch.
25 25  * Do not perform refactorings if
26 26   * you run into a big mess that you can't easily refactor and that still works.