Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[Global summit for java Devs 2021] Clean Architecture? Clean Code? Refactoring? Tests? What does this change in my code?

[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.


  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


  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 .

  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

  24. OO ABUSERS - SWITCH STATEMENTS Very complex switch statements or

    sequence of if statements @kamila_code

    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

  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

  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


  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