The document discusses refactoring code for simplicity and reducing technical debt. It defines refactoring as improving code without adding new functionality. Code smells are discussed as indicators that code may need refactoring, such as duplicate code, comments, and dead code. Specific refactoring techniques are provided for different types of code smells like dispensables and bloaters. Microservice bad smells are also examined like wrong service cuts, hardcoded endpoints, and shared databases. The document provides examples and references for further reading on refactoring code and microservices.
4. Quésaco?
• Process of improving code without
creating new functionality
• Fundamental step of TDD
• Fundamental concept in XP
5. Refactoring for code simplicity
• Every code is good until we need to change it
• Always write simple code
• Simple code = easy to refactor
6. Refactoring – Why? When? How?
• Why?
• Technical debt
• Dirty code
• Lot of bugs
• Changes are slow
7. Refactoring – Why? When? How?
• When?
• Rule of three
• When adding a feature
• When fixing a bug
• During code review
Computer Science is the discipline that believes all problems can be solved with one more layer of indirection.
—Dennis DeBruler
8. Refactoring – Why? When? How?
• How?
• The code should become cleaner.
• New functionality shouldn’t be
created during refactoring.
• All existing tests must pass after
refactoring.
11. Large-Scale Automated Refactoring Using
ClangMR
• https://ai.google/research/pubs/pub41342
• refactor large C++ codebases
• combination of the Clang compiler framework and the MapReduce parallel
processor
13. Code Smells
Psychology:
• a piece of code contains some issues VS a piece of code contains some smells, that it is
"smelly"
14. Code Smells – The Dispensables
• Comments/duplicate code/dead code
• P: uncessary, less clarity
• S: Rename Method, Extract Method
• Payoff: Simplification + shortness = code
that’s easier to simplify and cheaper to
support.
15. Code Smells – The Bloaters
• Data Clumps
• P: poor program structure
• S: Introduce Parameter Object, Preserve
Whole Object.
• Payoff: Operations on particular data are
now gathered in a single place, reduced
code size.
Warning: undesirable dependency between the
classes.
17. Code Smells – Change Preventers
• Data Clumps
• P: poor program structure
• S: Introduce Parameter Object, Preserve
Whole Object.
• Payoff: Operations on particular data are
now gathered in a single place, reduced
code size.
Warning: undesirable dependency between the
classes.
18. Code Smells – Couplers
• Feature Envy
• P: A method accesses the data of another
object more than it’s own.
• S: Move Method, Extract Method, Move
Field.
• Payoff: Less code duplication, higher
cohesion.
Warning: intentionnally keeping data away, e.g
: Strategy, Visitor...
19. Refactoring and Performance
• != school of thought that ignores performance in favor of design purity or in
hopes of faster hardware.
• If you optimize all the code equally, you end up with 90 percent of the
optimizations wasted
• Profiling ensures you focus that time on the right place
21. Microservice Bad Smells - Survey
• Microservice Smells: indicators of situations—such as undesired patterns,
antipatterns, or bad practices—that negatively affect software quality attributes such
as understandability, testability, extensibility, reusability, and maintainability of the
system under development.
• Interviewed 72 experienced developers
• Duration of the survey: two years
• Detected 11 bad smells
22. Microservice Bad Smells - Survey results
• Very harmful:
• Wrong Cuts, Hard-Coded Endpoints,
and Shared Persistency
• Difficult to remove:
• Wrong Cuts, Microservice Greedy, and
Too Many Standards
23. Microservice Bad Smells - Why
• lack of experience
• most problems in the early stage (6 months to year)
• Architecture & Design issues, e.g ESB
24. Wrong Cuts
• Desc: wrong split
• Problem: wrong separation of concerns and increased data-splitting
complexity
• Solution: clear analysis of business, DDD
25. Hard-Coded Endpoints
• Desc: Hardcoded IP addresses and ports
• Problem: locations need to be changed
• Solution: service discovery
26. Shared Persistency
• Desc: same relational database or worst same entities
• Problem: reducing team and service independence
• Solution: private database or private schema
27. Microservice Greedy
• Desc: needless microservices
• Problem: useless huge system that will easily
become unmaintainable
• Solution: clear analysis of the need, DDD
28. Too Many Standards
• Desc: many development languages,
protocols, frameworks..
• Problem: lot of required skills, developer
turnover..
• Solution: use carefully, don’t follow the latest
hype.
30. References
• Refactoring: Improving the Design of Existing Code - Book
• Microservices AntiPatterns and Pitfalls - Book
• On the Definition of Microservice Bad Smells – Research
• Refactoring: Improving the Design of Existing Code – Book
• https://refactoring.guru
