Slide 1

Slide 1 text

CLEAN ARCHITECTURE? CLEAN CODE? REFACTORING? TESTS? WHAT DOES THIS CHANGE IN MY CODE? Kamila Santos

Slide 2

Slide 2 text

Hi Folks, I’m Kamila Santos Backend Developer at Ame Digital github.com/kamilahsantos in/kamila-santos-oliveira/ @kamilah_santos kamila_code

Slide 3

Slide 3 text

Clean Code Clean code is simple and easy to follow, with isolated scope, easy to be tested, and well (self) documented

Slide 4

Slide 4 text

Clean Code “Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ” Martin Fowler

Slide 5

Slide 5 text

Clean Code Be consistent Scout rule RASAP KISS

Slide 6

Slide 6 text

Clean Code Use names that reveal the intention

Slide 7

Slide 7 text

Clean Code Use Pronounceable / Searchable names

Slide 8

Slide 8 text

Clean Code Don’t define names with what you find most beautiful / cute

Slide 9

Slide 9 text

Clean Code Choose a word by Idea / Concept

Slide 10

Slide 10 text

Clean Code Clean code is obvious for other developers

Slide 11

Slide 11 text

Clean Code Clean code doesn't contain duplicate code

Slide 12

Slide 12 text

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