Unlearn Modularity

Transcript

1. Co-Founder & Software Crafter @ Craftgate LEMi ORHAN ERGiN MODULARITY D I U N L E A R N
2. of what we build as software is %90 CRAP
3. of what we build as software is %90 CRAP sturgeon's law: ninety percent of everything is crap most of what we built was mediocre even we care high quality, we do not know what it really is we believe in common explanations written in blog posts we do not dare to take the time to understand it in depth
4. the entropy of software increases over time measure of the disorder or randomness in a system
5. the entropy of software increases over time entropy is not a result, it has degrees Systems are prone to entropy. In software, as in nature, complexity increases unless work is done to maintain order - Fred Brooks (Author of The Mythical Man-Month) the goal of development should be keeping software predictable & less chaotic
6. common mis-beliefs about software entropy
7. common mis-beliefs about software entropy continuous refactoring exists write code today to refactor later write code to never delete, extend whatever it takes customer needs should fi t our existing design modular design is a good design
8. how complex systems survive and keep enthropy low?
9. Assembly Theory tries to explain how complex systems form and survive Assembly Theory
10. Complex objects (molecules, structures, etc.) arise by combining smaller parts in a step-by-step process. The more steps needed, the more "assembled" and complex the object. Assembly happens over time, and a complex object re fl ects a history of its construction process Assembly theory allows complexity to be measured by counting the steps required to create something. 1 2 3 Assembly Theory concept from physics & biology to explain how complex systems arise through a process of sequential assembly
11. Assembly Theory concept from physics & biology to explain how complex systems arise through a process of sequential assembly Software is developed by assembling reusable modular components, that is functions, classes, libraries, multiple layers, integrations, APIs, and components interacting in de fi ned sequences Technical debt can be viewed as steps in the assembly process that happen in time with complexity leading to future problems 1 2 3 Abstraction simpli fi es the assembly process, making complex systems easier to build by reducing the amount of detailed assembly required Refactoring and automated testing are the process of simplifying the structure, making the steps of assembly clearer and more maintainable 4 IN SOFTWARE DEVELOPMENT CONTEXT independent, interchangeable, a part that constitutes a whole
12. common mis-beliefs about modularity
13. common mis-beliefs about modularity grouping code into fi les and folders breaking code into smaller pieces adding new layers of abstraction high cohesion, low coupling event based architecture layered architecture using oop drawing and focusing on boxes using microservices completely decouple components having modules code will be modular by …
14. in software development to grow code and survive the formulation of the reduction of entropy
15. in software development to grow code and survive decrease complexity & increase modularity by balancing coupling =( ) the formulation of the reduction of entropy Reference: Balancing Coupling Software Design book, by Vlad Khononov
16. amazon.com/Balancing-Coupling-Software-Design-Addison-Wesley-ebook/dp/B09RV3Z3TP learning.oreilly.com/library/view/balancing-coupling-in/9780137353514 I read every single word written in Balancing Coupling in Software Design book. The book deserves to be in the top 10 in software design. I cannot recommend it more. Do yourself a favor, get it now and read it to the end. twitter.com/lemiorhan/status/1841903400117797271 - Lemi Orhan Ergin
17. coupling fasten together
18. coupling fasten together coupling is a bad thing it shows poor design completely decouple have independent components common mis-beliefs
19. coupling core design tool connected glued together can affect each other integrated in the system upstream component downstream component purpose business functionality bounded context interaction contract system boundary knowledge magnitute all the degrees between weak and tight interconnected set of components having a purpose habitat of knowledge how familiar about each other passing knowledge out of boundaries cohesion type of coupling, grouping related business capabilities together in a single module or bounded context provides a functionality to be consumed consumes upstream’s functionality interface exposing knowledge balancing
20. core design tool connected glued together can affect each other integrated in the system coupling working functionalities never guarantee future growth and fl exibility without having the right balance in coupling upstream component downstream component purpose business functionality bounded context interaction contract system boundary knowledge magnitute loose/weak, tight/strong interconnected set of components having a purpose habitat of knowledge how familiar about each other passing knowledge out of boundaries cohesion type of coupling, grouping related business capabilities together in a single module or bounded context provides a functionality to be consumed consumes upstream’s functionality interface exposing knowledge balancing coupling higher degree the more knowledge modules share, the higher likelihood that they will need to change together
21. cyne fi n: decision making environments CLEAR COMPLICATED COMPLEX CHAOTIC DISORDER straightforward predictable best practices documented insuf fi cient info known unknowns consult expert search for help insuf fi cient info unknown unknowns no expert no one knows no best practice context speci fi c experiment trial and error unpredictable inconsistent no experiments no consulting trust your instinct transform to complex no awareness cannot categorize cannot understand disorganized unmanagable investigate to learn how dif fi cult it is to understand, explain, or predict a system or model validating a web form submission peformance optimization in database queries user experience design sudden crash of a server uncertainty encountered when starting a new project
22. fi complexity is an essential part of our lives because it is in everywhere tight interactions, more components, high cognitive load uncontrolled complexity leads to chaotic CLEAR COMPLICATED COMPLEX CHAOTIC DISORDER
23. Degrees of Freedom (DOF) refers to how many independent variables or options a system, function, or program can adjust or change how much control or fl exibility you have when working with something more degree of freedom means more fl exibility, but more shared knowledge and more complexity FREEDOM HAS CONSEQUENCES
24. cause unintended effects or in unexpected ways linear interactions clear and predictable LOW DOF HIGH DOF complex/non-linear interactions
25. what causes complexity? size, component number, interactions? Complexity isn’t about size or the number of components, but the unpredictable (non-linear) interactions between components. It is not the number of components that produces complexity, but the interaction among them. - Charles Perrow professor of sociology at Yale University on organizational theory and the sociology of risk https://press.princeton.edu/books/paperback/9780691004129/normal-accidents
26. Alan Kay imagined objects as independent machines acting like biological cells, operating on their own isolated state, and communicating via message passing The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay from Alan’s email about “Prototypes vs Classes” h tt p://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html ALAN KAY’S SCHOOL OOP objects were originally designed as modules
27. building systems with components without having to know details of how they work Module handling the cognitive load while growing knowing the interactions between modules is enough to learn how it works ARITY MODUL
28. Module Function knowledge boundary enclosing speci fi c functionality exposing public interface/api to other modules WHAT? Implementation Details implementation, algorithms and design decisions hidden from customers HOW? Context environment that de fi nes the relationship of the module with other modules WHERE? WHO?
29. People were doing a bad job of dividing the work into modules. Those modules had very complex interfaces, and changes almost always affected many modules. - David L. Parnas pioneer on modularity and information hiding in software systems that’s where DDD means a lot!
30. METRICS OF MODULES EVALUATING HOW BALANCED THE COUPLING ARE
31. integration strength how much knowledge that is shared other modules Reference: Balancing Coupling Software Design book, by Vlad Khononov Payment API MASTER REPLICA Report API Save payment Retrieve payment Generate report Search payment Read Write Read QUEUE produce event consume event Vlad uses “integration strength” to mean what I mean by “coupling”. - Kent Beck from Vlad’s Balancing Coupling book
32. distance the closest common ancestor of two modules Reference: Balancing Coupling Software Design book, by Vlad Khononov Payment Installment pos selection algorithm pos selection algorithm Playground pos selection algorithm API API Methods in the same object Objects in the same namespace/package Objects in different namespaces/packages Different libraries Services in a distributed system Systems implemented by different vendors close: far: coherence bigger cognitive load
33. volatility how often they are expected to change in time Reference: Balancing Coupling Software Design book, by Vlad Khononov Even the most pristine system may evolve into a big ball of mud over time, as changing requirements, developer turnover, and lack of refactoring take their toll. - Brian Foote and Joseph Yoder, Big Ball of Mud essay https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
34. volatility how often they are expected to change in time Reference: Balancing Coupling Software Design book, by Vlad Khononov A timeless goal of software engineering has been to separate code that changes frequently from code that is stable. - Jim Coplien, from Lean Architecture book https://www.amazon.com/Lean-Architecture-Agile-Software-Development/ dp/0470684208
35. volatility how often they are expected to change in time Reference: Balancing Coupling Software Design book, by Vlad Khononov If your model is telling a story, the modules are chapters. It isn’t just code being divided into modules, but concepts. - Eric Evans, the pioneer on Domain Driven Design https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity- Software/dp/0321125215
36. volatility how often they are expected to change in time Reference: Balancing Coupling Software Design book, by Vlad Khononov AGGREGATE BUSINESS RULES DOMAIN MODEL BOUNDED CONTEXT
37. the balance having enough strength, distance and volatility Reference: Balancing Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced
38. the balance having enough strength, distance and volatility Reference: Balancing Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced UNBALANCED
39. the balance having enough strength, distance and volatility Reference: Balancing Coupling Software Design book, by Vlad Khononov for the sake of managing maintenance, cost and stability strength distance volatility HIGH HIGH HIGH HIGH HIGH LOW HIGH LOW HIGH LOW HIGH HIGH LOW LOW HIGH HIGH LOW LOW LOW HIGH LOW LOW LOW LOW high global complexity loose coupling maintenance effort HIGH LOW LOW LOW HIGH LOW LOW LOW unstable high cohesion unchanged legacy system stable, loose coupling low cost, high cohesion low cost, stable, local complexity high local complexity balanced HIGH STABILITY, LOW COST
40. The goal of architecture is to facilitate the development, deployment, and maintenance of the system over time. That means that the architecture must balance modularity and coupling. Systems that are tightly coupled or poorly modularized become increasingly hard to sustain over time. - Robert C. Martin from the book “Clean Architecture”
41. speakerdeck.com/lemiorhan lemi orhan ergin co-founder, craftgate Evolution of Code to Modularity twitter.com/lemiorhan