![Code Smell
“Bad code smells are symptons of poor design or
implementation choices”
[Martin Fowler]
● Pragmatic: code smells should be considered on a case by case basis
● Purist: all code smells should be avoided, no exceptions](https://image.slidesharecdn.com/codesmelloverview-161221090645/85/Code-smell-overview-6-320.jpg)
Code smell overview
- 1. Code Smell Re-define refactoring at NAL (& code review) Lan@NAL 201612
- 2. Once upon a time We have “Code Review” on own SDP (Software Development Process), we always said “do refactoring", but ...
- 3. Once upon a time We did not know own code have bad smells, until ...
- 4. NOT BAD
- 5. Code Smell Martin Fowler https://martinfowler.com/bliki/CodeSmell.html "A code smell is a surface indication that usually corresponds to deeper problem in the system." In computer programming, code smell is any symptom in the source code of program that possibly indicates a deeper problem. Code smells are usually not bugs, they are not technically incorrect and do not currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future. "A code smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem." Kent Beck http://wiki.c2.com/?CodeSmell Code Smells = Warning Signs Code Smell ≠ A problem
- 6. Code Smell “Bad code smells are symptons of poor design or implementation choices” [Martin Fowler] ● Pragmatic: code smells should be considered on a case by case basis ● Purist: all code smells should be avoided, no exceptions
- 7. Code Smell (taxonomy) Smells Between Classes Smells Within Classes Object-orientation Abusers Bloaters Dispensables Change Preventers Couplers Others Encapsulation Abstraction Modularity Hierarchy
- 8. Code Smell Bad Smells: ● Bloaters ● Object-orientation Abusers ● Change Preventers ● Dispensables ● Couplers
- 9. Code Smell Bloaters Bloater smells represents something that has grown so large that it cannot be effectively handled. Long Method: A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions. Large Class: A class contains many fields/methods/lines of code. Long Parameter List: More than three or four parameters for a method. Data Clumps: Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database). Primitive Obsession: Use of primitives instead of small objects for simple tasks (such as
- 10. Code Smell Object-orientation Abusers All these smells are incomplete or incorrect application of object- oriented programming principles. Switch Statements: have a complex switch operator or sequence of if statements. Temporary Field: Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they are empty. Refused Bequest: If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions. Alternative Classes with Different Interfaces: Two classes perform identical functions but have different method
- 11. Code Smell Change Preventers These smells mean that if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more complicated and expensive as a result. Divergent Change: You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products. Shotgun Surgery: Making any modifications requires that you make many small changes to many different classes. Parallel Inheritance Hierarchies: Whenever you create a subclass for a class, you find yourself needing to create a subclass for another class.
- 12. Code Smell Dispensables A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand. Comments: A method is filled with explanatory comments. Duplicate Code: Two code fragments look almost identical. Lazy Class: Understanding and maintaining classes always costs time and money. So if a class doesn't do enough to earn your attention, it should be deleted. Data Class: A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters). These are simply containers for data used by other classes. These classes do not contain any additional functionality and cannot independently operate on the data that they own. Dead Code: A variable, parameter, field, method or class is no longer used (usually because it is obsolete). Speculative Generality: There is an unused class, method, field or parameter.
- 13. Code Smell Couplers All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation. Feature Envy: A method accesses the data of another object more than its own data. Inappropriate Intimacy: One class uses the internal fields and methods of another class. Message Chains: In code you see a series of calls resembling $a->b()- >c()->d() Middle Man: If a class performs only one action, delegating work to another class, why does it exist at all?
- 14. Code Smell Others Incomplete Library Class: Sooner or later, libraries stop meeting user needs. The only solution to the problem – changing the library – is often impossible since the library is read-only.
- 15. SO WHAT?!
- 16. Refactoring In real world, WORKING WITH CODE ... 20% Write new code 80% Modify existing code
- 17. Refactoring ● Unreadable Code … ● Duplicated Code … ● Complex Code … … Bad Smell Code is HARD to MODIFY
- 18. Refactoring Refactoring is ... ● Easier to Understand ● Cheaper to Modify “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”
- 19. Refactoring Code Smells Software Quality Code Quality READ High Quality Code = easy to UNDERSTAND CHANGE In the Long Run, High Quality Code Costs less Refactoring process ~ create Quality Code
- 20. Refactoring Request Review Review Comment Refactoring Repeat Commit Code Code Review ● Choose worst bad smell ● Select a refactoring ● Apply the refactoring ● Run all tests
- 21. Refactoring
- 22. Refactoring “With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.” So… HOWto do refactoring in a controlled and efficient manner?!
- 23. More reading/explore ● Refactoring: Improving the Design of Existing Code (by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts ● Refactoring Workbook (By William C. Wake) ● http://www.slideshare.net/mariosangiorgio/clean- code-and-code-smells ● http://mikamantyla.eu/BadCodeSmellsTaxonomy.ht ml
Editor's Notes
- #2: Nhìn lại hoạt động coding review & refactoring (tái định nghĩa trong NAL)
- #3: Chúng ta có Coding Review trong quy trình, có nói về Refactoring ... nhưng có lẽ không hiểu mục đích và cách làm các công việc này giống nhau.
- #4: Chúng ta không biết là Code của mình THỐI, cho đến khi khách hàng nói code của chúng ta thối.
- #8: Bloaters Bloater smells represents something that has grown so large that it cannot be effectively handled. Bloaters are code, methods and classes that have increased to such gargantuan proportions that they are hard to work with. Usually these smells do not crop up right away, rather they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them). Object-Orientation Abusers All these smells are incomplete or incorrect application of object-oriented programming principles. Change Preventers These smells mean that if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more complicated and expensive as a result. Dispensables A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand. Couplers All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation. --------- Abstraction: “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.” Encapsulation: “Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.” Modularity: “Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules Hierarchy: “Hierarchy is a ranking or ordering of abstractions.”
- #15: Incomplete Library Class Sooner or later, libraries stop meeting user needs. The only solution to the problem – changing the library – is often impossible since the library is read-only.