[Global summit for java Devs 2021] 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?
2. Backend developer at Ame Digital, Microsoft MVP, Book co- author, community co-organizer, content creator at kamila_code Kamila Santos @kamila_code
3. WHAT ARE WE GOING TO TALK ABOUT TODAY ? @kamila_code
4. CLEAN CODE @kamila_code CODE SMELLS TESTS CLEAN ARCH REFACTORING
5. CLEAN CODE Clean code is simple and easy to follow , with isolated scope , easy to be tested , and well (self ) documented @kamila_code
6. CLEAN CODE “Any fool can write code that a computer can understand . Good programmers write code that humans can understand . ” Martin Fowler @kamila_code
7. CLEAN CODE Be consistent @kamila_code
8. CLEAN CODE Scout rule : Always leave the code better than you found it . ... @kamila_code
9. CLEAN CODE RASAP : Refactor as soon as possible . @kamila_code
10. CLEAN CODE KISS : keep it simple stupid @kamila_code
11. CLEAN CODE Use names that reveal the intention @kamila_code
12. CLEAN CODE Use Pronounceable / Searchable names @kamila_code
13. CLEAN CODE Don 't define names with what you find most beautiful / cute @kamila_code
14. CLEAN CODE Choose a word by Idea / Concept @kamila_code
15. CLEAN CODE Clean code is obvious for other developers @kamila_code
16. CLEAN CODE Clean code doesn 't contain duplicate code @kamila_code
17. CODE SMELLS is completely opposite to the clean code @kamila_code
18. BLOATERS Code , methods and classes that have grown too much , accumulate over time as the program evolves @kamila_code
19. BLOATERS - LARGE CLASS A class that contains many lines of code , methods and fields . @kamila_code
20. BLOATERS - PRIMITIVE OBSESSION Use string constants as field names and constants for code information :USER _ADMIN _ROLE = 1 @kamila_code
21. BLOATERS - LONG PARAMETER LIST More than four parameters for a method @kamila_code
22. BLOATERS - DATA CLUMPS Parts of code that contain identical groups of variables (such as parameters of externals configs) @kamila_code
23. OBJECT- ORIENTATION ABUSERS Incorrect or incomplete application of OOP principles @kamila_code
24. OO ABUSERS - SWITCH STATEMENTS Very complex switch statements or sequence of if statements @kamila_code
25. OO ABUSERS - ALTERNATIVE CLASSES WITH DIFFERENT INTERFACES Two or more class perform identical functions but have different methods names @kamila_code
26. CHANGE PREVENTERS If you need to change something in one place of your code , you have to make many changes in other places too @kamila_code
27. DISPENSABLES something unnecessary and meaningless, the absence of which would make the code more efficient, easier to understand and cleaner @kamila_code
28. DISPENSABLES Duplicate Code, Comments and Dead Code @kamila_code
29. COUPLERS Contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation @kamila_code
30. REFACTORING 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. @kamila_code
31. TECHNICAL DEBT Consists of additional rework costs caused by choosing the easiest / fastest solution instead of using the best solution that would take longer @kamila_code
32. CAUSES OF TECHNICAL DEBT Lack of well -defined development standards or lack of knowledge on the part of the team @kamila_code
33. CAUSES OF TECHNICAL DEBT postpone writing tests until later and never write @kamila_code
34. CAUSES OF TECHNICAL DEBT Business pressure , short lead time @kamila_code
35. CAUSES OF TECHNICAL DEBT lack of communication @kamila_code
36. CAUSES OF TECHNICAL DEBT think about improving the code later and never come back @kamila_code
37. WHEN TO REFACTOR ? as soon as possible @kamila_code
38. WHEN TO REFACTOR ? During a code review @kamila_code
39. WHEN TO REFACTOR ? When adding a feature @kamila_code
40. WHEN TO REFACTOR ? When fixing a bug @kamila_code
41. WHEN TO REFACTOR ? when you go through the code and see the possibility of it being improved (and you can invest time in it ) @kamila_code
42. HOW TO REFACTOR A CODE ? The new code needs to be cleaner than the previous one @kamila_code
43. HOW TO REFACTOR A CODE ? the new code should be better performing than the previous one @kamila_code
44. HOW TO REFACTOR A CODE ? New functionalities shouldn ’t be created during refactoring @kamila_code
45. SIMPLIFYING METHOD CALLS This technique make methods calls simplier and easier to use , modifying the interfaces for interaction @kamila_code
46. COMPOSING METHODS In this category we remove code duplication , simplifies methods and prepares application for other refactorings . @kamila_code
47. ORGANIZING DATA helps with data handling and untangling of excessive class associations . @kamila_code
48. MOVING FEATURES BETWEEN OBJECTS Teach how safely move features between classes , hide implementation details and create new classes . @kamila_code
49. SIMPLIFYING CONDITIONAL EXPRESSIONS Reduce and improve conditional expressions @kamila_code
50. COMPOSING METHODS @kamila_code
51. EXTRACT METHOD Problem: a method with more than one responsibility, which can be extracted for a new method @kamila_code
52. @kamila_code
53. @kamila_code
54. ORGANIZING DATA @kamila_code
55. @kamila_code REPLACE NUMBER WITH SYMBOLIC CONSTANT Problem: you have a code that can be represented by a constant
56. @kamila_code
57. @kamila_code
58. TESTS @kamila_code
59. TEST SUITE collection of test cases or specs designed to test a program for a specific behavior @kamila_code
60. TEST SUITE Test suites are usually divided according to the functionality of the system or the type of test performed @kamila_code
61. TEST CASE Test Case shows the paths taken by a module , Use Case or functionality within the project . @kamila_code
62. UNIT TEST test each code functionality separately , each unit of it @kamila_code
63. JUNIT Platform for building and executing tests , @kamila_code
64. JUNIT PLATFORM Discovery and test execution in the JVM @kamila_code
65. JUNIT PLATFORM exposes the TestEngine interface , which defines the execution contract for any testing tool on the JUnit platform @kamila_code
66. JUNIT JUPITER Contains new features for building tests using JUnit , and provides a TestEngine implementation for running tests written with JUnit Jupiter . @kamila_code
67. JUNIT VINTAGE Provides a TestEngine for running tests written in JUnit 3 and 4 @kamila_code
68. ASSERTS 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 @kamila_code
69. ASSERTS There are several types of asserts like boolean , null ... @kamila_code
70. ANNOTATIONS is a special form of syntactic metadata that can be added to the Java source code for better readability and code structure @kamila_code
71. @kamila_code
72. @kamila_code
73. @kamila_code
74. BEST PRACTICES standard test case names: testSampleServiceCreateOrder () @kamila_code
75. BEST PRACTICES Always try to make a statement for each test method @kamila_code
76. BEST PRACTICES establish minimum coverage per project / pull request @kamila_code
77. BEST PRACTICES Test only one unit of code at a time @kamila_code
78. BEST PRACTICES Make each test independent of all others @kamila_code
79. BEST PRACTICES Name your tests cleanly and consistently @kamila_code
80. EXAMPLE @kamila_code
81. CLEAN ARCHITECTURE @kamila _code the clean coder blog
82. CLEAN ARCHITECTURE it tries to provide a way to organize the code so that it encapsulates the business logic and remains separate from the rest of the application and cannot be accessed directly @kamila _code
83. INDEPENDENT OF FRAMEWORKS @kamila _code TESTABLE
84. INDEPENDENT OF UI @kamila _code INDEPENDENT OF DATABASE
85. EXAMPLE @kamila _code
86. CONCLUSION about the clean architecture, it helps to better separate the responsibilities of the application, the negative point is that there is a much larger number of files and requires a certain amount of learning time to understand what each module / package is for @kamila _code
87. CONCLUSION this can also occur with other architectures and design patterns, it is worth evaluating what will improve in the application and if the team understands how to apply @kamila _code
88. CONCLUSION implanting the test culture can be complicated, mainly because it increases the development time including the tests, but it is one more way to always guarantee the functioning of the business rules of the system @kamila _code
89. CONCLUSION in addition to the techniques mentioned here of refactoring there are several other techniques that help a lot, for those who have the culture of TDD refactoring is already part of the development cycle, so it is easier to remember this stage in development @kamila _code
90. CONCLUSION having unit tests also helps new people who join the project to understand the business rules and find bugs more easily @kamila _code
91. THAT'S ALL FOLKS https://linktr.ee/kamila.dev thank you very much and add me on social networks on the link above to keep in touch and answer questions about the presentation @kamila_code