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

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

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
  70. None
  71. None
  72. None
  73. None
  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
  83. None
  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