![Refactoring – Best Practices
• Small Steps
• Test Often
• Write missing unit-tests
• Pair-programming
• Add before remove
• Use TODO and [Obsolete] midway](https://image.slidesharecdn.com/effectiverefactoring-181029120113/85/Effective-refactoring-14-320.jpg)
Effective refactoring
- 1. Effective Refactoring Arnon Axelrod Copyright © SELA Software & Education Labs, Ltd. | 14-18 Baruch Hirsch St., Bnei Brak 51202, Israel | www.selagroup.com
- 3. What is Refactoring? restructuring existing computer code, without changing its external behavior
- 4. Clean Code
- 6. Clean Code • Readability – Naming – Formatting • Method length • Number of parameters • Modularity and Reusability – Law of Demeter – Avoid static and Singletons • Exception Handling
- 7. Law of Demeter Method f in class C should only call methods of: C An object created by f An object passed as an argument to f An object held by an instance variable of C Counter example: string outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
- 8. The SOLID principles • Single Responsibility • Open/Close • Liskov Substitution • Interface Segregation • Dependency Inversion
- 9. 4 Rules of Simple Design / Kent Beck • Passes all the tests • Reveals the intent • No duplication (DRY) • Fewest elements (YAGNI) (order matters)
- 10. Poka Yoke
- 11. Poka Yoke - examples • private/public • readonly fields and get-only properties • Use classes instead of strings and integers • Use most specific interfaces – E.g. IReadOnlyCollection<T> instead of List<T>
- 12. Strong Typing With strong typing: With primitive types:
- 13. Refactoring / Martin Fowler
- 14. Refactoring – Best Practices • Small Steps • Test Often • Write missing unit-tests • Pair-programming • Add before remove • Use TODO and [Obsolete] midway
- 15. Add Before Remove public class SomeClass { public SomeClass() { //... } public void Foo(int someParam) { // use someParam... } } Initial state
- 16. Add Before Remove public class SomeClass { private int _someParam; public SomeClass(int someParam) { //... _someParam = someParam; } public void Foo() { // use _someParam... } } Final (desired) state
- 17. Add Before Remove public class SomeClass { public SomeClass() { //... } public void Foo(int someParam) { // use someParam... } } Initial state
- 18. Add Before Remove public class SomeClass { public SomeClass() { //... } private int _someParam; public SomeClass(int someParam) : this() { _someParam = someParam; } public void Foo(int someParam) { //use someParam... } } Step1 – Add constructor overload
- 19. Add Before Remove public class SomeClass { private int _someParam; public SomeClass(int someParam) { //... _someParam = someParam; } public void Foo(int someParam) { //use someParam... } } Step2 – Remove old constructor overload
- 20. Add Before Remove public class SomeClass { private int _someParam; public SomeClass(int someParam) { //... _someParam = someParam; } public void Foo(int someParam) { //use someParam... } public void Foo() { Foo(_someParam); } } Step3 – Add new overload of Foo
- 21. Add Before Remove public class SomeClass { private int _someParam; public SomeClass(int someParam) { //... _someParam = someParam; } public void Foo() { //use _someParam... } } Step4 (final) – Remove old overload of Foo
- 24. Resharper Refactorings • Rename • Extract Method/Inline method • Change Signature • Introduce variable/Inline variable • Introduce field/Inline field • Introduce parameter/Inline parameter • Transform parameters (to new class) • Convert Property to Method(s)/Convert • Convert Extension Method to Static/Convert Static to Extension Method • Convert Interface to Abstract Class/Convert Abstract Class to Interface • Replace Constructor with Factory method • Move Instance Method, Move to Another Type • Safe Delete • And more…
- 25. Inline Method
- 26. Change Signature
- 27. Introduce Field
- 29. Pull Members Up
- 32. Convert Property to Method(s)
- 33. Move to Another Type
- 34. Code Analysis
- 36. Summary • Clean code is essential for productivity and quality • Refactoring is essential to keep clean code • It’s important to learn and practice Clean Code and Refactoring • Mastering the tools will make you hyper-productive!
- 37. Questions
Editor's Notes
- #3: באתי מהכיוון של Clean code ו-Unit tests לתחום הבדיקות האוטומטיות. היום אני רוצה לחזור כי לדעתי שם נמצאות הבעיות האמיתיות...
- #4: The goal: to improve maintainability It’s not: A complete rewrite Bug fixing Changing a technology (to some extent) Behavior is contextual What are the boundaries of the refactored system? Is “performance” considered behavior Is CPU and memory consumption behavior? Is Reflection should be preserved? Exceptions (backward compatibility) Does the bits should be preserved…? We should know our presumptions
- #6: But really: Amount of time spent on debugging and understanding of code Makes it easier to prove correctness and avoid bugs Makes it easy and safe to make changes
- #7: רשימה חלקית, ממש על קצה המזלג, של הכללים שנכללים תחת הקטגוריה של Clean code
- #9: Many of these principles rely on Polymorphism which is based on the concept of callback functions. This is a concept that developers must master
- #11: בא לידי ביטוי בארכיטקטורה, בקוד ובתהליכי העבודה (למשל strongly typed)
- #17: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #18: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #19: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #20: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #21: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #22: להחליף תמונה TDD provides a safety net Caution: If tests are bad, refactoring can be more difficult than without! On the other hand, TDD drives for good tests Small steps, climbers rule
- #35: Value Tracking Call Tracking Type Hierarchy