From edca4461101d8efc061c07f619b01e7647fe6cab Mon Sep 17 00:00:00 2001 From: damithc Date: Wed, 4 Aug 2021 15:44:05 +0800 Subject: [PATCH] refactoring: Add more info on code smells and technical debt Inspired by the PR https://github.com/se-edu/se-book/pull/108 from @tlylt --- refactoring/when/resources.md | 5 +++++ refactoring/when/text.md | 21 ++++++++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 refactoring/when/resources.md diff --git a/refactoring/when/resources.md b/refactoring/when/resources.md new file mode 100644 index 0000000000..e0ef49615a --- /dev/null +++ b/refactoring/when/resources.md @@ -0,0 +1,5 @@ + + +* A list of code smells, symptoms, and remedies: https://refactoring.guru/refactoring/smells + + \ No newline at end of file diff --git a/refactoring/when/text.md b/refactoring/when/text.md index 3062873b9f..e731da7430 100644 --- a/refactoring/when/text.md +++ b/refactoring/when/text.md @@ -6,12 +6,31 @@
-You know that it is important to refactor frequently so as to avoid the accumulation of ‘messy’ code which might get out of control. But how much refactoring is too much refactoring? **It is too much refactoring when the benefits no longer justify the cost.** The costs and the benefits depend on the context. That is why some refactorings are ‘opposites’ of each other (e.g. [_extract method_](https://refactoring.com/catalog/extractMethod.html) vs [_inline method_](https://refactoring.com/catalog/inlineMethod.html)). +**One way to identify refactoring opportunities is by _code smells_.** + +> A _code smell_ is a surface indication that usually corresponds to a deeper problem in the system. +> First, a smell is by definition something that's quick to spot. Second, smells don't always indicate a problem.
+> --adapted from [https://martinfowler.com/bliki/CodeSmell.html](https://martinfowler.com/bliki/CodeSmell.html) + +An example (from the same source as above) is the code smell _data class_ i.e., a class with all data and no behavior. When you encounter the such a class, you can explore if refactoring it to move the corresponding behavior into that class is appropriate. Some more examples: +* [Long Method](https://refactoring.guru/smells/long-method) +* [Large Class](https://refactoring.guru/smells/large-class) +* [Primitive Obsession](https://refactoring.guru/smells/primitive-obsession) +* [Temporary Field](https://refactoring.guru/smells/temporary-field) +* [Shotgun Surgery](https://refactoring.guru/smells/shotgun-surgery) + +**Periodic refactoring is a good way to pay off the _technical debt_** a code base has accumulated. + +> Software systems are prone to the build up of **cruft** - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further.Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.
+> --[https://martinfowler.com/bliki/TechnicalDebt.html](https://martinfowler.com/bliki/TechnicalDebt.html) + +While it is important to refactor frequently so as to avoid the accumulation of ‘messy’ code (aka technical debt), an important question is how much refactoring is _too much_ refactoring? **It is too much refactoring when the benefits no longer justify the cost.** The costs and the benefits depend on the context. That is why some refactorings are ‘opposites’ of each other (e.g. [_extract method_](https://refactoring.com/catalog/extractMethod.html) vs [_inline method_](https://refactoring.com/catalog/inlineMethod.html)).
+