JLOVE CONF - Clean Architecture? Clean Code? Refactoring? Tests? What does this change in my code?

In this talk we will cover concepts and applications of clean architecture, clean code, when and how to refactor our code and why it is important to write tests, with examples in Java and Spring Boot. I intend to pass on some good development practices that I have been learning and are widely used in the market.

Transcript

1. CLEAN ARCHITECTURE? CLEAN CODE? REFACTORING? TESTS? WHAT DOES THIS CHANGE IN MY CODE? Kamila Santos
2. Hi Folks, I’m Kamila Santos Backend Developer at Ame Digital github.com/kamilahsantos in/kamila-santos-oliveira/ @kamilah_santos kamila_code
3. Clean Code Clean code is simple and easy to follow, with isolated scope, easy to be tested, and well (self) documented
4. Clean Code “Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ” Martin Fowler
5. Clean Code Be consistent Scout rule RASAP KISS
6. Clean Code Use names that reveal the intention
7. Clean Code Use Pronounceable / Searchable names
8. Clean Code Don’t define names with what you find most beautiful / cute
9. Clean Code Choose a word by Idea / Concept
10. Clean Code Clean code is obvious for other developers
11. Clean Code Clean code doesn't contain duplicate code
12. is completely opposite to the clean code Code smells
13. Code, methods and classes that have grown too much, accumulate over time as the program evolves Bloaters https://refactoring.guru/refactoring/smells/bloaters
14. A class that contains many lines of code, methods and fields. Bloaters - Large Class https://refactoring.guru/refactoring/smells/bloaters
15. Use string constants as field names and constants for code information USER_ADMIN_ROLE  1 Bloaters - Primitive Obsession https://refactoring.guru/refactoring/smells/bloaters
16. More than four parameters for a method Bloaters - Long Parameter List https://refactoring.guru/refactoring/smells/bloaters
17. Parts of code that contain identical groups of variables (such as parameters of externals configs) Bloaters - Data Clumps https://refactoring.guru/refactoring/smells/bloaters
18. Incorrect or incomplete application of OOP principles Object-Orientation Abusers https://refactoring.guru/refactoring/smells/oo-abusers
19. Very complex switch statements or sequence of if statements OO Abusers - Switch Statements https://refactoring.guru/refactoring/smells/oo-abusers
20. 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
21. 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
22. 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
23. Duplicate Code, Comments and Dead Code Dispensables https://refactoring.guru/refactoring/smells/dispensables
24. Contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation Couplers https://refactoring.guru/refactoring/smells/couplers
25. 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
26. "I'll do it later" Technical debt
27. Lack of well-defined development patterns Causes of technical debt
28. Delayed (or never done) refactoring Causes of technical debt
29. Lack of interaction between team members Causes of technical debt
30. Absence of documentation and tests and updating them Causes of technical debt
31. Business pressure Causes of technical debt
32. During a code review When to refactor?
33. When adding a feature When to refactor?
34. When fixing a bug When to refactor?
35. when you go through the code and see the possibility of it being improved (and you can invest time in it) When to refactor?
36. The new code needs to be cleaner than the previous one how to refactor a code?
37. New functionalities shouldn’t be created during refactoring, how to refactor a code?
38. This technique make methods calls simplier and easier to use, modifying the interfaces for interaction Simplifying Method Calls
39. In this category we remove code duplication, simplifies methods and prepares application for other refactorings. Composing Methods
40. helps with data handling and untangling of excessive class associations. Organizing Data
41. Teach how safely move features between classes, hide implementation details and create new classes. Moving Features between Objects
42. Reduce and improve conditional expressions Simplifying Conditional Expressions
43. Move functionally along the class inheritance hierarchy,i.e create new interfaces and classes and replacing inheritance with delegation. Dealing with Generalization
44. Composing Methods
45. Problem: a method with more than one responsibility, which can be extracted for a new method Extract Method
46. Extract Method
47. Extract Method
48. Organizing Data
49. Problem: you have a code that can be represented by a constant Replace Number with Symbolic Constant
50. Replace Number with Symbolic Constant
51. Replace Number with Symbolic Constant
52. Simplifying Method Calls
53. Problem: a method returns a value instead of an Exception Replace Error Code with Exception
54. Replace Error Code with Exception
55. Replace Error Code with Exception
56. Tests
57. collection of test cases or specs designed to test a program for a specific behavior Test Suite
58. Test suites are usually divided according to the functionality of the system or the type of test performed Test Suite
59. Test Case shows the paths taken by a module, Use Case or functionality within the project. Test Case
60. test each code functionality separately, each unit of it Unit Test
61. Platform for building and executing tests, Junit
62. Discovery and test execution in the JVM Junit Platform
63. exposes the TestEngine interface, which defines the execution contract for any testing tool on the JUnit platform Junit Platform
64. Contains new features for building tests using JUnit, and provides a TestEngine implementation for running tests written with JUnit Jupiter. Junit Jupiter
65. Provides a TestEngine for running tests written in JUnit 3 and 4 Junit Vintage
66. 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
67. There are several types of asserts like boolean, null ... Asserts
68. Asserts
69. is a special form of syntactic metadata that can be added to the Java source code for better readability and code structure Annotations
74. standard test case names: testSampleServiceCreateOrder () Best practices
75. Always try to make a statement for each test method Best practices
76. Don't pass the test just to pass it! Best practices
77. Coverage and test report Best practices
78. Mock your data Best practices
79. Test only one unit of code at a time Best practices
80. Make each test independent of all others Best practices
81. Name your tests cleanly and consistently Best practices
82. All methods, regardless of visibility, must have appropriate unit tests Best practices
84. CLEAN ARCHITECTURE Imagem de https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
85. Independent of Frameworks
86. Testable
87. Independent of UI
88. Independent of Database
89. 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
90. 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
91. 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
92. Example https://github.com/Kamilahsantos/jloveconf-cleanarchitecture
93. Example
94. Example
95. Example
96. Conclusion separating these layers is not easy, but separating them from the beginning makes the code more testable and easier to maintain.
97. General conclusion these techniques / methodologies / standards are widely used and recommended.
98. General conclusion Among the techniques, clean architecture is the most difficult to implement and it is worth considering the learning curve
99. 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
100. Thanks <3 Other social networks, examples and slides in qrcode Linkedin https://www.linkedin.com/i n/kamila-santos-oliveira/ Twitter @kamilah_santos