Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tricks for Isolated Architecture in Ruby - Sergey Kukunin

84 views

Published on

Ruby Meditation #15
May 13, 2017
Dnipro, I Coworking Hub

Published in: Technology
  • Be the first to comment

Tricks for Isolated Architecture in Ruby - Sergey Kukunin

  1. 1. Tricks for Isolated Architecture in Ruby Ruby Meditation #15, May 13 2017
  2. 2. I am Sergiy And I’ve been searching a silver bullet for a while BTW, my twitter is @sergey_kukunin Hello!
  3. 3. I work at , Lviv
  4. 4. The Humble Programmer “we shall be able to design and implement the kind of systems that are now straining our programming ability, at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs” by Edsger W. Dijkstra, 1972, http://bit.ly/2pHGbhF
  5. 5. The Humble Programmer ● intellectually manageable programs ● proof of correctness ● the amount of intellectual effort depends on the program length ● the influence of the tool we are trying to use upon our own thinking habits ● hierarchy
  6. 6. The Humble Programmer “In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 1010 or more”
  7. 7. Two values of software The secondary value of software is its behavior. 1 Defined by Uncle Bob Martin in episode 9 (‘The Single Responsibility Principle’) of his CleanCoders video series
  8. 8. The primary value of software is that it’s soft. The ability of software to tolerate and facilitate such ongoing change is the primary value of software. 2
  9. 9. Conclusions ● Programming is complicated ● Programming is risky ● Programming is expensive That’s why we should care about what we write.
  10. 10. Symptoms of Rotting Design ◉ Rigidity - the tendency for software to be difficult to change ◉ Fragility - the tendency of the software to break in many places every time it is changed ◉ Immobility - the inability to reuse software from other projects or from parts of the same project ◉ Viscosity - two forms: viscosity of the design, and viscosity of the environment http://bit.ly/2rawutr
  11. 11. Other criterias ◉ Deployability ◉ Developability ◉ Comprehensibility
  12. 12. Every technique has own advantages and overhead. Sometimes, a technique doesn’t fit. You’re the one who is solely responsible for the code quality of your project. Disclaimer:
  13. 13. “ The main enemy of software is complexity. To remain maintainable, software should be simple.
  14. 14. Complexity grows as application grows1
  15. 15. The biggest impact is made by solution modularity
  16. 16. Analyze of Sorting algorithms Bubble sort = O(N2 ) When N = 60, N2 = 3600 If we divide an array into two halves we’ll have 2 * (N/2)2 = 2 * (302 ) = 1800
  17. 17. Divide and Conquer
  18. 18. Divide and Conquer
  19. 19. Single Responsibility Principle ● Definition of responsibility ○ Should have only one reason to change file ● Works on class level as well as on module level ● + Decreases rigidity ● + Necessary step for modularity
  20. 20. Examples of SRP ● Localization ● Thread handling ● HTML/CSS/JS ● Interactors
  21. 21. Rely on interface, not on implementation
  22. 22. Example of interface
  23. 23. The less a module knows about siblings, the more independent it is. Keep encapsulation
  24. 24. Law of Demeter might indicates that current class knows too much. Does this look better?
  25. 25. Dependency Inversion Principle ● High-level policy should not be dependent upon low-level detail ● Main trick for decoupling ● + Decreases rigidity ● + Improves modularity/deployability ● + Better testing ● - Lines of code overhead
  26. 26. How it works: DI
  27. 27. How it works: DI
  28. 28. Dependency Injection
  29. 29. Isn’t this violation of encapsulation?
  30. 30. Integration of modules
  31. 31. IoC 1 ● Separates the application from the main. ● Fixes dependencies order. ● Decouples modules and classes. ● Decreases rigidity of the application.
  32. 32. Should be iterative, small and often Constant Refactoring
  33. 33. Boyscout Rule
  34. 34. Functional programming
  35. 35. Because functions are data First-class functions
  36. 36. Composability
  37. 37. Immutability
  38. 38. First-class tests ● Tests are proof of correctness ● They make you feel safe while refactoring ● Tests drive better design ● Tests should be trustful ● Tests should be fast
  39. 39. Test-driven development 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  40. 40. “ The only way to keep it simple is to make composition of abstractions
  41. 41. Simple software is readable software2 We read code even when we write code
  42. 42. Micro-level ◉ Small classes ◉ Small methods ◉ Intention-revealing methods ◉ Consistent indentation Readability Macro-level ◉ Ubiquitous language ◉ Unified model ◉ Domain-driven design
  43. 43. DDD separates domain-related code from platform-related 2
  44. 44. Domain layer: dry-types 1 ● Prevention of illegal state ● Types algebra ● Immutability ● Blazing fast
  45. 45. Application layer: CQS 1 defines application boundaries: data inside are trusted
  46. 46. Infrastructure layer 1 ● Independent implementations of 3rd-party services ● The easiest to extract to a gem ● Persistence is here
  47. 47. UI layer 1 ● An interface for interactive for the application ● HTTP delivery mechanism ● Validation is tied to an interface, not to an entity ● dry-validation
  48. 48. Persistence layer: ROM 1 ● Adapters ● Relations ● Mappers ● Repositories
  49. 49. Other advices ◉ Prefer instance methods over class methods ◉ Avoid singletons and global state ◉ Prefer pure functions
  50. 50. Real experience
  51. 51. Any questions ? You can find me at ◉ @sergey_kukunin ◉ sergiy@maticinsurance.com Thanks!

×