Changes for page Refactoring

Summary

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

Details

Page properties

Content

...	...	@@ -8,8 +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.
12		-* **Refactor in small steps.** Whenever tests pass, you can 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]].
	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.
	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.
15	15	1. **Refactoring**: Don't add new tests or new functionality, just improve existing functionality. Only add tests if you have overlooked something you have not yet tested. Having only one assertion per test is often a good guideline, but not a strict one, since it's sometimes practical to include multiple assertions within a single test if they are closely related and together validate a specific behavior.
...	...	@@ -26,7 +26,7 @@
26	26	* you run into a big mess that you can't easily refactor and that still works.
27	27	* a rewrite is cheaper.
28	28	* **Handling API Changes**: There may be a situation where you want to change a public API that clients depend on. A good approach is to simply add the new API, and when the clients are updated to work with the new API, the old API can be deleted.
29		-* **Dilemma of Refactoring Bad Legacy Code**: Legacy code often lacks tests. Before you start refactoring it, you should stabilize it by adding tests. The problem is that code designed without tests is really hard to write tests for. There is no easy solution: Directly refactoring the code runs the risk of introducing new bugs due to lack of tests, and writing tests is hard without prior refactoring. Probably the best approach is to break the code into pieces that are connected by APIs, to which tests can more easily be applied. This is still risky, since the changes are applied without tests, but it is smaller.
	29	+* **Dilemma of Refactoring Bad Legacy Code**: Legacy code often lacks tests. Before you start refactoring it, you should stabilize it by adding tests. The problem is that code designed without tests is really hard to write tests for. This leads to a dilemma: Directly refactoring the code runs the risk of introducing new bugs due to lack of tests, and writing tests first is hard without prior refactoring because the code was designed without testing in mind. The best approach is probably to break the code into pieces that are connected by APIs, to which tests can more easily be added afterwards. Once the tests are written, the actual refactoring can be done. This splitting process is still risky because the changes are applied without tests, but less risky than refactoring the entire code without tests.
30	30	* From a refactoring perspective, **it is advantageous to use statically typed languages because they have better tools**, e.g. renaming is much easier due to unambiguous types and naming. This can be a problem with dynamic languages, but the ultimate choice of language depends on more factors than just this.
31	31
32	32	### Performance Optimization