is completely opposite to
the clean code
Code smells
Slide 13
Slide 13 text
Code, methods and
classes that have grown
too much, accumulate
over time as the program
evolves
Bloaters
https://refactoring.guru/refactoring/smells/bloaters
Slide 14
Slide 14 text
A class that contains
many lines of code,
methods and fields.
Bloaters - Large
Class
https://refactoring.guru/refactoring/smells/bloaters
Slide 15
Slide 15 text
Use string constants as
field names and constants
for code information
USER_ADMIN_ROLE 1
Bloaters - Primitive
Obsession
https://refactoring.guru/refactoring/smells/bloaters
Slide 16
Slide 16 text
More than four
parameters for a method
Bloaters - Long Parameter
List
https://refactoring.guru/refactoring/smells/bloaters
Slide 17
Slide 17 text
Parts of code that contain
identical groups of
variables (such as
parameters of externals
configs)
Bloaters - Data Clumps
https://refactoring.guru/refactoring/smells/bloaters
Slide 18
Slide 18 text
Incorrect or incomplete
application of OOP
principles
Object-Orientation
Abusers
https://refactoring.guru/refactoring/smells/oo-abusers
Slide 19
Slide 19 text
Very complex switch
statements or sequence
of if statements
OO Abusers - Switch
Statements
https://refactoring.guru/refactoring/smells/oo-abusers
Slide 20
Slide 20 text
Two or more class perform
identical functions but have
different methods names
OO Abusers -
Alternative Classes with
Different Interfaces
https://refactoring.guru/refactoring/smells/oo-abusers
Slide 21
Slide 21 text
If you need to change
something in one place of
your code , you have to
make many changes in
other places too
Change Preventers
https://refactoring.guru/refactoring/smells/change-prev
enters
Slide 22
Slide 22 text
something unnecessary and
meaningless, the absence
of which would make the
code more efficient, easier
to understand and cleaner
Dispensables
https://refactoring.guru/refactoring/smells/dispensables
Slide 23
Slide 23 text
Duplicate Code,
Comments and Dead
Code
Dispensables
https://refactoring.guru/refactoring/smells/dispensables
Slide 24
Slide 24 text
Contribute to excessive
coupling between classes
or show what happens if
coupling is replaced by
excessive delegation
Couplers
https://refactoring.guru/refactoring/smells/couplers
Slide 25
Slide 25 text
Refactoring is the process
of changing a software
system in a way that it does
not change its external
behavior, but has an
improved internal structure.
Refactoring
Slide 26
Slide 26 text
"I'll do it later"
Technical debt
Slide 27
Slide 27 text
Lack of well-defined
development patterns
Causes of technical debt
Slide 28
Slide 28 text
Delayed (or never done)
refactoring
Causes of technical debt
Slide 29
Slide 29 text
Lack of interaction
between team members
Causes of technical debt
Slide 30
Slide 30 text
Absence of
documentation and tests
and updating them
Causes of technical debt
Slide 31
Slide 31 text
Business pressure
Causes of technical debt
Slide 32
Slide 32 text
During a code review
When to refactor?
Slide 33
Slide 33 text
When adding a feature
When to refactor?
Slide 34
Slide 34 text
When fixing a bug
When to refactor?
Slide 35
Slide 35 text
when you go through the
code and see the
possibility of it being
improved (and you can
invest time in it)
When to refactor?
Slide 36
Slide 36 text
The new code needs to
be cleaner than the
previous one
how to refactor a code?
Slide 37
Slide 37 text
New functionalities
shouldn’t be created
during refactoring,
how to refactor a code?
Slide 38
Slide 38 text
This technique make
methods calls simplier
and easier to use,
modifying the interfaces
for interaction
Simplifying Method Calls
Slide 39
Slide 39 text
In this category we
remove code duplication,
simplifies methods and
prepares application for
other refactorings.
Composing Methods
Slide 40
Slide 40 text
helps with data handling
and untangling of
excessive class
associations.
Organizing Data
Slide 41
Slide 41 text
Teach how safely move
features between classes,
hide implementation
details and create new
classes.
Moving Features between
Objects
Slide 42
Slide 42 text
Reduce and improve
conditional expressions
Simplifying Conditional
Expressions
Slide 43
Slide 43 text
Move functionally along the
class inheritance hierarchy,i.e
create new interfaces and
classes and replacing
inheritance with delegation.
Dealing with Generalization
Slide 44
Slide 44 text
Composing Methods
Slide 45
Slide 45 text
Problem: a method with
more than one
responsibility, which can
be extracted for a new
method
Extract Method
Slide 46
Slide 46 text
Extract Method
Slide 47
Slide 47 text
Extract Method
Slide 48
Slide 48 text
Organizing Data
Slide 49
Slide 49 text
Problem: you have a code
that can be represented
by a constant
Replace Number with Symbolic
Constant
Slide 50
Slide 50 text
Replace Number with Symbolic
Constant
Slide 51
Slide 51 text
Replace Number with Symbolic
Constant
Slide 52
Slide 52 text
Simplifying Method Calls
Slide 53
Slide 53 text
Problem: a method
returns a value instead of
an Exception
Replace Error Code with Exception
Slide 54
Slide 54 text
Replace Error Code with
Exception
Slide 55
Slide 55 text
Replace Error Code with
Exception
Slide 56
Slide 56 text
Tests
Slide 57
Slide 57 text
collection of test cases or
specs designed to test a
program for a specific
behavior
Test Suite
Slide 58
Slide 58 text
Test suites are usually
divided according to the
functionality of the system
or the type of test
performed
Test Suite
Slide 59
Slide 59 text
Test Case shows the
paths taken by a module,
Use Case or functionality
within the project.
Test Case
Slide 60
Slide 60 text
test each code
functionality separately,
each unit of it
Unit Test
Slide 61
Slide 61 text
Platform for building and
executing tests,
Junit
Slide 62
Slide 62 text
Discovery and test
execution in the JVM
Junit Platform
Slide 63
Slide 63 text
exposes the TestEngine
interface, which defines the
execution contract for any
testing tool on the JUnit
platform
Junit Platform
Slide 64
Slide 64 text
Contains new features for
building tests using JUnit, and
provides a TestEngine
implementation for running
tests written with JUnit
Jupiter.
Junit Jupiter
Slide 65
Slide 65 text
Provides a TestEngine for
running tests written in
JUnit 3 and 4
Junit Vintage
Slide 66
Slide 66 text
it is a useful method for
determining the Pass or Fail
status of a test case. Declaration
methods are provided by the
org.junit.Assert class that
extends the java.lang.Object
class
Asserts
Slide 67
Slide 67 text
There are several types of
asserts like boolean, null ...
Asserts
Slide 68
Slide 68 text
Asserts
Slide 69
Slide 69 text
is a special form of syntactic
metadata that can be added to
the Java source code for better
readability and code structure
Annotations
Slide 70
Slide 70 text
No content
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
No content
Slide 73
Slide 73 text
No content
Slide 74
Slide 74 text
standard test case names:
testSampleServiceCreateOrder ()
Best practices
Slide 75
Slide 75 text
Always try to make a statement
for each test method
Best practices
Slide 76
Slide 76 text
Don't pass the test just to pass it!
Best practices
Slide 77
Slide 77 text
Coverage and test report
Best practices
Slide 78
Slide 78 text
Mock your data
Best practices
Slide 79
Slide 79 text
Test only one unit of code at a
time
Best practices
Slide 80
Slide 80 text
Make each test independent of all
others
Best practices
Slide 81
Slide 81 text
Name your tests cleanly and
consistently
Best practices
Slide 82
Slide 82 text
All methods, regardless of
visibility, must have appropriate
unit tests
Best practices
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
CLEAN ARCHITECTURE
Imagem de https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Slide 85
Slide 85 text
Independent of Frameworks
Slide 86
Slide 86 text
Testable
Slide 87
Slide 87 text
Independent of UI
Slide 88
Slide 88 text
Independent of Database
Slide 89
Slide 89 text
Entities
"encapsulate Enterprise wide
business rules. An entity can be an
object with methods, or it can be a
set of data structures and
functions. " The Clean
Architecture
Slide 90
Slide 90 text
Use Cases
"contains application specific business rules. It
encapsulates and implements all of the use cases
of the system. These use cases orchestrate the
flow of data to and from the entities, and direct
those entities to use their enterprise wide
business rules to achieve the goals of the use
case." The Clean Architecture
Slide 91
Slide 91 text
Interface Adapters
"The software in this layer is a set of adapters
that convert data from the format most
convenient for the use cases and entities, to
the format most convenient for some external
agency such as the Database or the Web." -
The Clean Architecture
Slide 92
Slide 92 text
Example
https://github.com/Kamilahsantos/jloveconf-cleanarchitecture
Slide 93
Slide 93 text
Example
Slide 94
Slide 94 text
Example
Slide 95
Slide 95 text
Example
Slide 96
Slide 96 text
Conclusion
separating these layers is not easy, but
separating them from the beginning makes
the code more testable and easier to
maintain.
Slide 97
Slide 97 text
General conclusion
these techniques / methodologies /
standards are widely used and
recommended.
Slide 98
Slide 98 text
General conclusion
Among the techniques, clean architecture is
the most difficult to implement and it is
worth considering the learning curve
Slide 99
Slide 99 text
General conclusion
And that radically changes your code :D
facilitating the maintenance and addition of
new features, in addition to the integration
of new team members
Slide 100
Slide 100 text
Thanks <3
Other social networks, examples and slides in
qrcode
Linkedin
https://www.linkedin.com/i
n/kamila-santos-oliveira/
Twitter
@kamilah_santos