Domain Re-discovery Patterns for Legacy Code (v1) 🇬🇧 @DDD EU 2024

In the world of software development, legacy code often poses significant challenges. Existing codebases, built years ago, may lack documentation and understanding of the original domain. This lack of knowledge can hinder effective maintenance, upgrades, and feature development. The process of rediscovering the domain of legacy code is invaluable for developers seeking to enhance and extend these systems.

In this talk we'll delve into various domain re-discovery patterns that help in identifying and reconstructing the domain model that the legacy code represents. These patterns go beyond merely deciphering the code's functionality; rather, they provide strategies to comprehend the underlying concepts, behaviors, and relationships in the domain.

Attendees can expect to gain practical insights, methodologies, and practical tips to tackle the challenges associated with legacy codebases. By embracing domain rediscovery patterns, developers can bring order and coherence to legacy systems, paving the way for future enhancements and system evolution.

Transcript

1. 31.05.24 Richard Gross (he/him) Archaeology richargh.de/ speakerdeck.com/richargh @arghrich Hypermedia TestDSLs Domain Re-discovery Patterns for Legacy Code
2. Slides by richargh.de and Modernization Audit A lot of helpful rediscovery patterns 2 Modernization Project Passive Patterns (Analyze) Active Patterns (Change) Significantly longer 3 weeks
3. Slides by richargh.de and A lot of helpful rediscovery patterns 3 Passive Patterns (Analyze) Active Patterns (Change) Where to start What to try
4. Slides by richargh.de and Some Modernizations required dirtier patterns than others 4
5. Slides by richargh.de and Pattern categories 5 Capture the Intent Mine the Expert Mine the Repo Not the focus today
6. Slides by richargh.de and The Dirty (but useful) Patterns 6
7. Slides by richargh.de and Our highest priority is to satisfy the customer by not changing what doesn’t need changing. 7 The second principle of the legacy software manifesto (if one is ever written).
8. Slides by richargh.de and Passive Pattern: Activity Logging Context • Know which code parts are reached often and potentially critical • Know which code parts are not reached at all and are potentially obsolete Approach • Identify system entry points & deep interna, then log there • Alt: Prometheus Counter • Count in production Caveat • Some things are cyclical yearly/monthly (reports) 8
9. Slides by richargh.de and Active Pattern: Legacy Toggle Context • Know if a feature really is obsolete and deletable Approach • Add a UI toggle, count if activated (soft) • Deactivate in backend via env variable, reactivate env if someone complains (hard) • Increasing Thread.sleep before answer (evil) • Return static result, see if someone complains (rockstar) Caveat • Some things are cyclical (reports) • People still might not complain 9
10. Slides by richargh.de and 10 Capture the Intent Mine the Expert Mine the Repo
11. Slides by richargh.de and We’re working Backwards from Code 11 https://fs.blog/2013/07/the-difference-between-science-and-engineering/ IT Archaeology
12. Slides by richargh.de and Warning: we’ll be talking about metrics 1. ⚠ Every measure which becomes a target becomes a bad measure1 2. ⚠ Metric hotspots are only conversation starters 3. ⚠ The truth is in the conversation 12 1 https://en.wikipedia.org/wiki/Goodhart%27s_law
13. Slides by richargh.de and Warning: we’ll be talking about names 1. Naming is hard 2. Metrics tell us where to start refactoring 3. Refactoring helps us find what (new) concept to name 4. Finding a good name is still not immediate but a process 13 https://www.digdeeproots.com/articles/on/naming-process/
14. Slides by richargh.de and Passive Pattern: Code Tag Cloud1,2 Context • Get a high level overview of possible domain terms Approach • Generate a tag cloud from code by extracting either the names or the behaviors (invoked methods) Caveat • Repetition wins, not necessarily importance 14 1 Original Idea, probably by Kevlin Henney https://youtu.be/SUIUZ09mnwM?feature=shared&t=2226 2 Original tag cloud code: https://www.feststelltaste.de/word-cloud-computing/
15. Slides by richargh.de and Pattern: Code Tag Cloud Discover the modeled names 15 Generated with: https://github.com/Richargh/code-tagcloud-py-sandbox Generated from: https://github.com/spring-projects/spring-petclinic ./main.py ../oss/spring-petclinic/ java name Stringly or Strongly Typed?
16. Slides by richargh.de and Pattern: Code Tag Cloud Your domain can be quite rich 16 Generated with: https://github.com/Richargh/code-tagcloud-py-sandbox Generated from: https://github.com/ddd-by-examples/library ./main.py ../oss/ddd-library/ java name Where is “String”?
17. Slides by richargh.de and Pattern: Code Tag Cloud Your service offering dictates name richness 17 Generated with: https://github.com/Richargh/code-tagcloud-py-sandbox https://github.com/spring-projects/spring-petclinic https://github.com/ddd-by-examples/library Specific Service Generic/customizable Service https://github.com/MaibornWolff/codecharta/tree/main/visualization
18. Slides by richargh.de and Active Pattern: Strong1 Code Tag Cloud Bring the domain forward • Model your ids record UserId(String rawValue){} à Remove a bug source, see connections better • Primitive Value Objects • Is it a anything-goes string or are there domain constraints? • Does a number have significance, can you give it a name2 or type? • Elements that are always passed/returned together à is there a domain concept missing? 18 1 Opposite of stringly https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed 2 https://luzkan.github.io/smells/magic-number
19. Slides by richargh.de and We‘re now visualizing metrics with CodeCharta1 buildings Plug by Zaufishan Some icons by https://www.reshot.com/ Gource is a cool git visualizer https://gource.io/ CodeScene is a good Charta-alternative: https://codescene.com/ 1 CodeCharta is open-source https://maibornwolff.github.io/codecharta/ 19 f.ex. Complexity f.ex. Number of authors Lines of Code SomeService.kt
20. Slides by richargh.de and Passive Pattern: Cluster Invest Context • Grasp the modeled structure based on which parts had the most code invest Approach 1. Generate a tree-map of the code. 2. Highlight logical clusters that contain a lot of lines of code (LoC) Caveat • Shows accidental + essential complexity1 not necessarily importance 20 1 https://en.wikipedia.org/wiki/No_Silver_Bullet
21. Slides by richargh.de and Passive Pattern: Cluster Invest 21 Lines of Code N/A N/A CodeCharta Code visualized by CodeCharta https://maibornwolff.github.io/codecharta/ codemap ribbonbar searchPanel store datamocks.ts customConfigs Do the cluster names and sizes match domain expectations?
22. Slides by richargh.de and Active Pattern: Component Focus When you see no meaningful domain clusters Package by Layer (or other technicality) Package by component2 22 Controller A Controller B Service A Service B Repository A Repository B Controller A Service A Repository A Service B Repository B Controller B 1 This is a lot easier the more you have discovered from other patterns 2 https://dzone.com/articles/package-component-and Scan names in system entry points to find possible components1
23. Slides by richargh.de and Pattern: Complexity1 Invest Context • Cyclomatic complexity1 counts places where the control flow branches (if, for, catch, …). • A lot of complexity is an indicator that domain decisions are being made. Approach 1. In the code-map mark the places with a lot of complexity Caveat • Cyclomatic complexity penalizes switch cases heavily and ignores indendation2,3 23 1 McCabe‘s cyclomatic complexity (MCC) counts branches in control flow (if, for, while, catch) 2 Alternative: Cognitive Complexity https://www.sonarsource.com/resources/cognitive-complexity/ 3 Alternative: Indendation based „Bumby Road“ smell https://codescene.com/engineering-blog/bumpy-road-code-complexity-in-context/
24. Slides by richargh.de and Pattern: Complexity Invest 24 Lines of Code Cycl. Complexity Cycl. Complexity (high) CodeCharta Code visualized by CodeCharta https://maibornwolff.github.io/codecharta/ codemap ribbonbar searchPanel store datamocks.ts loadInitialFile.service.ts „Interesting, why is that so complex“? nodeDecorator.ts „Node from the tag cloud, what does it do?“ viewCube.component.ts „Complex but does not show up in tag cloud, why?“ customConfigs
25. Slides by richargh.de and Active Pattern: Complexity Limit • Remove indentation with guard clauses • switch(anEnum) { case “A”: doThingA() } à polymorphic dispatch anABCobj.doThing(); • Replace flag argument1 with specific methods • Separate presentation from domain from data2 • Finally group things that only interact with each other and extract as new type • You now have new domain concepts to name 25 1 Flag arguments https://martinfowler.com/bliki/FlagArgument.html 2 Presentation Domain Data Layering https://martinfowler.com/bliki/PresentationDomainDataLayering.html
26. Slides by richargh.de and Passive Pattern: Knowledge Silos Context • Code elements that are only changed by few authors are likely only understood by these authors. • If the elements are complex and only have one author, we have a business risk as well. Approach 1. In the code-map, mark complex elements that have only 1 or 2 authors. 2. Hightlight elements where the author is about to leave or has left. 26 See also https://codescene.com/knowledge-distribution
27. Slides by richargh.de and Passive Pattern: Knowledge Silos 27 Lines of Code metricColorRangeDiagram.component.ts Medium code, medium complex, but only one person knows about it Cog. Complexity Number of authors (low) CodeCharta Code visualized by CodeCharta https://maibornwolff.github.io/codecharta/
28. Slides by richargh.de and Active Pattern: Knowledge Sharing Context • Mitigate the business risk of knowledge silos Caveat • Having everyone know everything is time-consuming and wasteful due to forgetfulness Approaches • Simple code • Specification by (test) example • “Owner” delegates changes and reviews • Pair/Mob programming • Dev Talk Walkthrough 28 See also https://codescene.com/knowledge-distribution
29. Slides by richargh.de and Passive Pattern: Coordination Bottlenecks Context • Code elements that everyone changes usually require extensive coordination to avoid conflicts. Approach 1. In the code-map, mark complex elements where most of the team have made recent changes. 29
30. Slides by richargh.de and Passive Pattern: Coordination Bottlenecks 30 Lines of Code datamocks.ts Lot‘s of code, but no decisions. Probably fine. Cycl. Complexity Number of authors (high) CodeCharta Code visualized by CodeCharta https://maibornwolff.github.io/codecharta/ codeMap.mouseEvent.service.ts Lot‘s of code, many decisions and 20 authors. Why?
31. Slides by richargh.de and Passive Pattern: Multi-Level Dependency Graph Context • Imports between elements mean coupling • Code Coupling is (roughly) domain coupling • Any circle (tangle) creates knots in our brain Approach 1. Graph the import statements between elements. Stable elements (with no dependencies) at the bottom. 2. Mark arrows that go “up” in red, they create tangles1. 3. View graph, first on high-level, then focus on subsets. 31 1 https://structure101.com/help/java/studio/Content/xs/tangle.html
32. Slides by richargh.de and Passive Pattern: Multi-Level Dependency Graph 32 CodeCharta Code visualized by Dependency Cruiser https://github.com/sverweij/dependency-cruiser Alternative: Structure101 and tangles: https://structure101.com/help/cpa/studio6/Content/restructure101/tangles.html npx depcruise app/codeCharta/ --output-type dot | dot –T svg Tangle model à util à state à model
33. Slides by richargh.de and Passive Pattern: Temporal Coupling1 Context • If a change in A often requires a change in B, the elements are temporally coupled1. • The reason for this often invisible coupling is a high Connascence. Approach 1. Count how often A was commited together with B. If high draw A à B. 2. Count how often B was commited without A. If high don’t draw B à A. 3. In the code-map, mark these elements. 33 1 from the book https://pragprog.com/titles/atcrime/your-code-as-a-crime-scene
34. Slides by richargh.de and Passive Pattern: Temporal Coupling1 34 Lines of Code Cycl. Complexity Number of authors (high) 1 from the book https://pragprog.com/titles/atcrime/your-code-as-a-crime-scene CodeCharta Code visualized by CodeCharta https://maibornwolff.github.io/codecharta/ Ingoing Temporal Coupling codeMap Notice that no compile-time relation exists between the temporally coupled files.
35. Slides by richargh.de and How does temporal coupling happen? 35 B C A Temporal Coupling Static Coupling Both are forms of Connascence
36. Slides by richargh.de and 36 2 elements A,B are connascent if there is at least 1 possible change to A requires a change to B in order to maintain overall correctness. Connascence by Meilir Page-Jones, “Fundamentals of Object-Oriented Design in Uml”
37. Slides by richargh.de and Connascence of • Name: variable, method, SQL Table • Type: int, String, Money, Person • Meaning: what is true,‘YES‘,null,love • And 6 more Easy Hard on your brain Good Bad Connascence: https://www.maibornwolff.de/en/know-how/connascence-rules-good-software-design/
38. Slides by richargh.de and Connascence describes the type of coupling • Name (CoN) • Type (CoT) • Meaning (CoM) • And 6 more Easy Hard on your brain Static coupling Temporal coupling (Duplication) Refactor this way Connascence: https://www.maibornwolff.de/en/know-how/connascence-rules-good-software-design/ Expensive Change Cheap Hidden domain Explicit Domain
39. Slides by richargh.de and Connascence guides refactoring 39 CoN Alternative 1. // A) 2. enum MovieType { } 3. // B) 4. sealed interface Movie permits RegularMovie { } 3. // C) 4. interface Movie { 5. int amount(){ … } 6. } 7. // D) 8. // appropriate solution is a team effort 1. // A) 2. static int OLD_PEOPLE_PENALTY = 25; 3. // B) 4. // appropriate solution is a team effort J Connascence: https://www.maibornwolff.de/en/know-how/connascence-rules-good-software-design/ CoM
40. Slides by richargh.de and Active Pattern: Temporal decoupling • Find elements with lots of temporal coupling • Identify type of Connascence that leads to the coupling 1. Try to move strongly connascent elements closer to each other 2. Try to refactor to a connascence of lower strength 3. If all else fails, “lock” the connascent elements à move them to a place that won’t receive changes (2) Will usually uncover new domain concepts 40 Connascence: https://www.maibornwolff.de/en/know-how/connascence-rules-good-software-design/
41. Slides by richargh.de and Passive Pattern: Entity Ownership Context • Which part of the code “owns” an entity is highly related to which WRITEs to the table. • Only one code part should “own” an entity so it can protect its contract (invariants, pre-/post conditions) Approach 1. grep Reads: SELECT, JOIN 2. grep Writes: INSERT, UPDATE, DELETE 3. Table or plot for each entity which components reads an entity and which writes 41 1 https://structure101.com/help/java/studio/Content/xs/tangle.html
42. Slides by richargh.de and Passive Pattern: Entity Ownership 42 Read Write Scattered writes • Is entity contract protected everywhere? • Is entity contract in sync everywhere? Scattered reads • Does everyone really need the entity? • Does everyone need the same fields?
43. Slides by richargh.de and Active Pattern: Entity Ownership Bounds Only one write location • Don’t write the entity if you don’t own it • If you have to write, delegate to owner • The owner knows what a valid entity is Read • If scattered reads have little field overlap, consider splitting • Get feedback on domain names of splits • See if split has a different owner • Keep it in sync via events 43
44. Slides by richargh.de and 44 Capture the Intent Mine the Expert Mine the Repo
45. Slides by richargh.de and Characterization tests capture a snapshot of the system 45 Oracle-based testing Characterization testing1,2,3 Captures intended behavior Captures observed behavior Specific input assert actual matches expected One Test (often) Generated inputs assert actual matches snapshot Many Tests There are 2½ more testing types that we won‘t get into here. 1 see also „Golden Master“ https://en.wikipedia.org/wiki/Characterization_test 2 see approval test framework https://approvaltests.com 3 see verify framework https://github.com/VerifyTests/Verify/ „Classic“ testing Legacy-focused testing
46. Slides by richargh.de and Active Pattern: Inverse Object Mother Context • Learn the minimal domain and document it as code. Approach 1. Start application with empty database 2. Click through a UseCase 3. Analyse exceptions and errors • „App needs at least an object A with this field“ 4. Expand Domain Modell with your finding 5. Create required state in the DB with your model 6. Document finding as characterization test 7. Repeat 46
47. Slides by richargh.de and Active Pattern: Inverse Object Mother Approach 1. Start application with empty database 2. Click through a UseCase 3. Analyse exceptions and errors • „App needs at least an object A with this field“ 4. Expand Domain Modell with your finding 5. Create required state in the DB with your model 6. Document finding as characterization test 7. Repeat 47 1. // Required state, temporarily in main 2. // we’ll move this to test soon 3. void main() { 4. oneCharacterization(); 5. } 6. // characterizations have no concept of why 7. void displaysListOfBooksOnStart(){ 8. // needs a user 9. createUser(); 10. // needs at least one author 11. var author = createAuthor(); 12. // needs at least one book 13. var book = createBook(author); 14.}
48. Slides by richargh.de and Active Pattern: Outside-in Tests via Dsl Context • Keep tests structure- insensitive when you don’t know what your future structure will look like • Be able to convert integration tests to unit tests after remodelling Approach • Use an abstraction for the test setup. Don‘t let tests directly … • create entities • put entities into db • Stub out external systems • Write tests outside-in 48
49. Slides by richargh.de Active Pattern: Outside-in Tests via Dsl Start with an integration test 49 1. // create the low-level test-DSL 2. // small test, all secondary ports are now stubs or fakes, they never connect to the real world 3. const { a, secondaryPorts } = integrationTest().withoutState().buildDsl(); 4. 5. test(‘should be able to rent book’, () => { 6. // GIVEN 7. const book = a.book(); // I need a book, don’t care which 8. const { user } = a.userBundle(it => it.hasPermission(“CAN_RENT_BOOK”); // a user, don’t care who 9. 10. await a.saveTo(secondaryPorts); // store book and user entities in repositories 11. 12. const testee = configureRentingComponent(floor); // configure dependencies of component 13. // WHEN 14. const result = testee.rentBook(book, user); 15. // THEN 16. expect(result.isRented).toBeTrue(); 17.} <module>/renting.integration.test.ts
50. Slides by richargh.de Active Pattern: Outside-in Tests via Dsl Go unit with min. change, once all db logic is in domain 50 1. // create the low-level test-DSL 2. // small test, all secondary ports are now stubs or fakes, they never connect to the real world 3. const { a, secondaryPorts } = unitTest().withoutState().buildDsl(); 4. 5. test(‘should be able to rent book’, () => { 6. // GIVEN 7. const book = a.book(); // I need a book, don’t care which 8. const { user } = a.userBundle(it => it.hasPermission(“CAN_RENT_BOOK”); // a user, don’t care who 9. 10. await a.saveTo(secondaryPorts); // store book and user entities in repositories 11. 12. const testee = configureRentingComponent(floor); // configure dependencies of component 13. // WHEN 14. const result = testee.rentBook(book, user); 15. // THEN 16. expect(result.isRented).toBeTrue(); 17.} <module>/renting.unit.test.ts
51. Slides by richargh.de and Always look for opportunities to document domain-understanding with oracle tests You want to start with characterization tests as a safety-net 51
52. Slides by richargh.de and Active Pattern: Annotation-Whiskers Context • Types are great for modeling but they are quite invasive, especially when you are not yet sure of the end result • Instead we’ll use annotations to model assumptions and check them statically Approach 0. Select an annotation-checker1 1. Use existing annotation or write your own 2. Run static analysis 3. Fix errors or make new assumption (go back to 2) 4. If useful, model as type 52 When you just want the null-checking, the options depend on your language http://richargh.de/talks/#fixing-the-billion-dollar-mistake 1 the checker framework is good for this in java https://checkerframework.org/
53. Slides by richargh.de and Active Pattern: Annotation-Whiskers As annotation1 Vs as type (when you are sure) 53 1. @m int meters = 5 * UnitsTools.m; 2. @s int seconds = 2 * UnitsTools.s; 3. 4. // allowed 5. @mPERs int speed = meters / seconds; 6. 7. // produces a compile-error 8. @m int foo = meters + seconds; 1. Meters meters = Meters.of(5); 2. Seconds seconds = Seconds.of(2); 3. 4. // allowed 5. Speed speed = meters.per(seconds); 6. 7. // produces a design-time error 8. var foo = meters.plus(seconds); 1 uses the checker framework https://checkerframework.org/
54. Slides by richargh.de and Active Pattern: North-Star Architecture Context • At some point we want to write new code but still have so much confusing legacy • We want to make sure we’re all working toward the same goal • We don’t want to wait with feature development until everything is shiny Approach 0. Define the north-star: the architecture you desire 1. Codify north-star1,2,3 2. Freeze existing violations 3. Continuously run static analysis 4. Fix new violations immediately 54 1 Using ArchUnit for Java https://www.archunit.org/ 2 TSArch for TS/JS https://github.com/ts-arch/ts-arch 3 or Dependency Cruiser for TS/JS https://github.com/sverweij/dependency-cruiser
55. Slides by richargh.de and Active Pattern: North-Star Architecture 55 1. @ArchTest 2. static final ArchRule no_classes_should_depend_on_service = 3. freeze( // accept existing violations 4. noClasses() 5. .should() 6. .dependOnClassesThat() 7. .resideInAPackage("..service..")); 8. @ArchTest 9. static final ArchRule services_should_not_access_controllers = 10. noClasses() // only green without violations 11. .that().resideInAPackage("..service..") 12. .should().accessClassesThat().resideInAPackage("..controller.."); Example uses ArchUnit https://www.archunit.org/
56. Slides by richargh.de and Communication Pattern: Quality Views1 Context • Your domain re-discovery is going to take years • It’s best to communicate where new features are easy and where they are hard Approach 1. Draw your code structure 2. Colorize based on ease-of-change 1. Explicit web-Api? 2. Enforced component bounds? 3. Presentation-Data-Domain Layering 4. Categorization tests? 5. Significant oracle tests? 6. If you can‘t quantify, fist-of-five-itTM 3. Mark what you work on right now 56 1 Based-on https://blog.colinbreck.com/using-quality-views-to-communicate-software-quality-and-evolution/
57. Slides by richargh.de and Communication Pattern: Quality Views Highest-Level 57 Increasing changeability Better Worse Pricing Renting Invoicing Component Locked Transforming for future features Focus Slight quality dip since last communication No changes planned or wanted
58. Slides by richargh.de and Communication Pattern: Quality Views Zoom in 58 Increasing changeability Better Worse Pricing search quote Renting book Invoicing bill liquidate Component Capability Locked Feature-planning often requires more details Focus
59. Slides by richargh.de and Why all the effort to re- discover? We could just start a-new! 60
60. Slides by richargh.de and The True Cost of Feature-based Rewrites Features Releases over time Catch Up Missing Features Sub-Par Parity Enhancements Planned Rewrite Actual Features Undiscovered Scope Old App Adoption Original Article by Doug Bradbury The True Cost of Rewrites
61. Slides by richargh.de Thanks 62 Richard Gross (he/him) richargh.de/talks @arghrich Works for maibornwolff.de/ People. Code. Commitment. DE TN ES Slides, Code, Videos Contact me <firstname>.<lastname> at maibornwolff de Cartography Contact CodeCharta at https://maibornwolff.github.io/codecharta/ Code Tag Cloud at https://github.com/Richargh/code-tagcloud-py-sandbox TestDsl Code at https://github.com/Richargh/testdsl Archaeology + Audits Hypermedia TestDSLs Ask me about these topics J
62. Slides by richargh.de and Backup
63. Slides by richargh.de and The cost of the rewrite depends on your approach Feature-based rewrite • Goal = Feature + Feature + Feature • Incrementally build feature after feature • Release when all are done Outcome-based rewrite • Goal = achieve an outcome • Write the minimal thing to achieve outcome • Iterate 65
64. Slides by richargh.de and Generate and view a CodeCharta map 66 npm install -g codecharta-analysis git clone git@github.com:MaibornWolff/codecharta.git ccsh sonarimport https://sonarcloud.io -o petclinic.code.cc.json ccsh gitlogparser repo-scan --repo-path=spring-petclinic/ -o petclinic.git.cc.json ccsh merge petclinic.git.cc.json.gz petclinic.code.cc.json.gz -o petclinic.cc.json à Open petclinic.cc.json.gz in https://maibornwolff.github.io/codecharta/visualization/app/index.html The official docs: https://maibornwolff.github.io/codecharta
65. Slides by richargh.de and How do we refactor what we don‘t understand? 73 Slides by @arghrich Autumn: Product Baseline
66. Slides by richargh.de and 74 Slides by @arghrich Autumn: Product Baseline Emily Bache @emilybache „Nopefactoring“ The No-thinking refactoring“ Advanced Testing & Refactoring Techniques • Lift-up conditional • Split to Classes Llewellyn Falco @LlewellynFalco Cutting Code Quickly
67. Slides by richargh.de and A brief coupling primer High Coupling Low Cohesion Low Coupling High Cohesion 75 Coupling Unknown Source
68. Slides by richargh.de and Connascence Guides Refactoring • Name: variable, method, SQL Table • Type: int, String, Money, Person • Meaning: what is true,‘YES‘,null,love • Position: order of value • Algorithm: encoding, SPA vs Server • Execution (order): one before other • Timing: doFoo() in 500ms | doBar() in 400ms • Value: constraints on value, invariants • Identity: reference same entity Easy Hard on your brain Good Bad Really Bad Refactor this way Connascence: 🇩🇪 https://www.maibornwolff.de/know-how/connascence-regeln-fuer-gutes-software-design/
69. Slides by richargh.de and 4-axes of Connascence Strength Level How explicit Locality How close Degree Number of Impacts Volatiliy How much change
70. Slides by richargh.de and The 4½ types of testing 78 Oracle-based testing Property-based testing1 Characterization testing2,3 Metamorphic testing4 Captures intended behavior Captures observed behavior Captures intended properties Random inputs assert one property of all outputs Captures intended metamorphic relations One Test Specific input assert actual matches expected One Test (often) Generated inputs assert actual matches snapshot Many Tests One source, Derived inputs assert outputs keep relation to source One Test The remaining ½ is the mutation which you can use to test your tests. Mutate code, run test, see if enough tests break. 1 see jqwik https://jqwik.net/ 2 see also „Golden Master“ https://en.wikipedia.org/wiki/Characterization_test 3 Alternative name, „Approval Tests“ including test framework https://approvaltests.com 4 see https://www.hillelwayne.com/post/metamorphic-testing/
71. Slides by richargh.de and Metamorphic testing 79 Input Output testee x f(x) g(x) g(f(x)) testee Derive via metamorphic relation Assert Check if relation holds